V2 lives in a new repository, but it is of course built on Version one. The tracker is still at its core and around it, OnTime now handles teams, invoices and payments.

What changed

In V1, one person tracked their own time but in V2, everything happens inside workspaces. A workspace can consist of just you or a whole team and every member has one of four roles: owner, admin, manager or member.

But the basics are of course still there: a timer, manual entries and clients, projects and tasks with their own detail pages. The calendar is now shared and even updates live across devices. Projects can have budgets that send a notification when they cross a threshold. The whole app is in English and German and on mobile it works offline thanks to a persisted query cache.

Invoices and payments

This is where V2 changes the most from its previous version. Billable time becomes an invoice and when you send it, an Edge Function renders it as a PDF and freezes it. If you edit the underlying time entries later, the document the client already received doesn’t change.

Additionally, OnTime connects to your bank through Enable Banking. The connection is read-only by design and you bring your own credentials, which are stored encrypted in Supabase Vault. A scheduled pg_cron job pulls in transactions and matches them against open invoices. When a match is confident, the invoice is marked paid automatically. Everything else waits in a queue for one-click review.

Database changes

V1’s database only had to serve one person tracking their own hours. V2 needed a real data model, so I didn’t patch the old schema and started from the start.

As said before, Everything belongs to a workspace: Clients, projects, tasks, time entries and invoices all hang off a workspace and every row knows which workspace it belongs to. That one change is what makes teams possible. It’s also what the security model is built on.

Also, every table has row-level security policies that check the caller’s workspace and role before returning a single row. Views run with security_invoker, so they apply the permissions of the person querying them instead of quietly bypassing them. Owners, admins, managers and members all hit the same tables and get different answers. Since the frontend isn’t trusted to enforce any of this, pgTAP suites test the rules against a real database.

Another security measure was to add a timestamp to entries when they get deleted. Now they are moved to a trash view, where they can be restored. A pg_cron job purges them for good once they’ve been in the trash long enough, so nobody has to clean up by hand.

An invoice can’t point at time entries and hourly rates, because those can change or be edited. When an invoice is sent, it stores a JSONB snapshot of everything it was built from and the PDF is frozen alongside it. Rates also keep a history, so billing a project in March uses March’s rate even if it went up in June. Invoice numbers are generated per workspace and restart each year.

pg_cron also triggers the bank sync so that transactions come in on a schedule, get matched against open invoices and confident matches mark the invoice as paid. The bank credentials never sit in a plain column and are encrypted in Supabase Vault.

The shared calendar and the notifications subscribe to database changes through Supabase Realtime. When someone stops a timer on their phone, the entry shows up on everyone else’s desktop without a refresh.

Testing

Tests run in three layers:

• Vitest for units and components
• Playwright end-to-end tests against a preview build
• pgTAP for the security rules

Unit and end-to-end coverage are combined into one number and uploaded to Codecov on every CI run. Right now I have about 40% coverage but that will still be improved in later versions.

The post OnTime V2 appeared first on Mobile USTP MKL.

The project is still in development, and its name, complete concept, and current interface are intentionally not public yet. This article therefore does not present a product reveal. Instead, it focuses on the design process between March and August 2026: how the interface developed from functional wireframes into a more coherent visual system, how collaboration influenced the result, and how repeated feedback changed my understanding of clarity, accessibility, and visual identity.

The app was developed during the second semester of the Master Interactive Media program. Its technical foundation is an iOS application written in Swift, but this project was mainly concerned with screen design and brand development. The public scope covers the basic screens already named in the development article: home, calendar and list overviews, related detail pages, and forms for calendar entries, list items, and reminders.

Beginning with structure

The first design phase consisted of wireframes for these core functions. At that point, the goal was not to decide on colors, fonts, or icon styles. The wireframes were used to understand information hierarchy and navigation: What should appear first on the home screen? How much information belongs in an overview? When does an item need its own detail page? Which actions should be immediately available, and which can remain one level deeper?

This phase was deliberately simple. Boxes represented content areas, placeholder text represented labels, and navigation elements were reduced to their basic purpose. It also exposed how quickly a planning interface can become crowded. Even the basic screens combine dates, titles, statuses, categories, actions, navigation, and secondary information. The home screen needed to offer orientation, overviews had to support scanning, and forms required a more guided rhythm.

One important lesson from this stage was that visual hierarchy begins before visual styling. If the structure does not make priorities clear, stronger colors and larger headings only make the confusion more visible. The early wireframes therefore became a reference throughout the later process. Whenever a refined screen started to feel overloaded, I could return to the basic structure and ask whether the added visual elements were supporting the original purpose or competing with it.

From wireframes to the first design screens

The next phase translated the wireframes into the first designed screens. This was the point where the project began to develop a personality. Typography, rounded forms, color relationships, icons, cards, borders, and spacing were introduced. The interface was meant to feel personal and approachable, so the first visual direction leaned strongly toward a playful style.

At first, this seemed appropriate. Planning is a daily and personal activity, and a playful interface offered a contrast to the strict appearance of many productivity tools. However, this phase also demonstrated that friendliness and playfulness are not the same thing. As more screens were added, decorative forms, multiple outlines, different icon styles, and expressive typography created too many points of attention. What worked as an isolated detail did not always work as part of a growing system.

The first design screens were therefore valuable precisely because they were not final. They made the intended personality visible, but they also revealed where that personality needed more discipline. The project had reached the stage where individual screens could no longer be evaluated only as attractive compositions. They had to work as one product.

Collaboration as a design process

During the visual development, I worked with a graphic design student who was responsible for developing the logo and the custom icons and who also proposed directions for the color concept. She is not named here, but her role in the process was substantial. I acted as the stakeholder for the application: I explained the intended character and requirements, reviewed ideas and intermediate states, and made decisions about how the graphic work should connect to the interface.

The collaboration was not organized as a single briefing followed by a finished delivery. She shared sketches, variants, and intermediate states, and we discussed which qualities felt appropriate while the interface itself was evolving. I often approached an element through function: Is the icon understandable? Can the asset be used consistently in Swift? Her perspective added questions of visual rhythm, shape language, balance, and recognition.

The logo and icons became important anchors for the emerging identity. Their development introduced more organic forms into a product that still needed a clear structure. This tension became one of the most useful ideas in the project: the interface could be calm and organized without becoming cold, and it could retain distinctive, playful details without allowing every component to become expressive.

The color proposals connected the graphic identity to the screen design, but applying a palette to an interface is different from presenting it in a visual study. Colors that look balanced together may not provide enough contrast for text, and a shade that works in an illustration may be too prominent across a large card. The collaboration provided the visual material, while the interface work tested it under practical conditions.

Feedback from recurring test users

Alongside the design collaboration, I repeatedly showed the screens to approximately five test users. The group was not statistically representative; its value came from continuity. The same people saw several stages and could react to changes over time.

Two issues appeared repeatedly: text was sometimes too small, and the contrast between text and background colors was sometimes too weak. The feedback revealed the difference between designing at full size on a computer and using the result on a phone. A composition can look spacious in a design tool while becoming tiring at actual device size. Because users need to identify dates, items, categories, and actions quickly, readability is part of the core interaction rather than an accessibility layer added later.

In response, font sizes were reconsidered, text colors were strengthened, and some relationships between foreground and background were simplified. The process also made me more cautious about using color to create hierarchy. If several shades are close in brightness, they may create a harmonious palette but fail to establish a useful reading order. Contrast has to work both aesthetically and functionally.

The users also identified screens that felt too busy even when every individual element was understandable. Familiarity reduces perceived complexity: after working on a screen for a long time, I already know where to look, while a test user does not. The central question gradually changed from whether the design looked friendly to whether it helped users feel oriented.

Moving from playful to calm

The strongest change between the first designs and the refined screens was the overall design language. The earlier versions were visibly more playful. Over time, the interface became quieter, clearer, and more structured. This did not mean removing all personality. Instead, playful qualities were concentrated in selected places, particularly in organic forms and custom icon details, while the main layout became more restrained.

Color was the most challenging part of this transition. The palette had to communicate warmth and individuality without reducing legibility or making the interface visually heavy. Several versions were needed before the relationship between light surfaces, darker functional elements, and accent colors felt balanced. The final direction is less about using many colors and more about giving each color a clear role.

The refinement also affected borders, cards, spacing, and typography. Reducing unnecessary boundaries allowed alignment to do more of the organizational work. Headings, secondary information, form labels, and actionable text received clearer roles. The typeface could support personality, but size, weight, spacing, and contrast had to support usability.

The same principle applied to iconography. Custom icons helped preserve the organic and personal character of the project, but an icon family also needs internal rules. Stroke weight, level of detail, filled and outlined states, and the relationship between icon and label all affect consistency. The icon work therefore became more than a collection of illustrations. It became the beginning of a visual grammar.

Designing a system rather than isolated screens

By the refinement stage, the screen set included the home screen, calendar and list overviews, calendar and list detail pages, and the add forms for calendar entries, list items, and reminders. Although this remains only the basic functional scope, it is already broad enough to expose inconsistencies. A heading that works on the home screen may occupy too much space in a form. A card that works for an upcoming event may not work for a list item. A navigation control that feels obvious on an overview may be ambiguous on a detail page.

This encouraged a more systematic approach. Instead of adjusting every screen independently, I began to think in reusable decisions: spacing intervals, text roles, card behavior, icon states, color functions, and recurring navigation patterns. This is also where the design process connected directly to the Swift implementation. Reusable SwiftUI components are easier to create when the visual rules are clear. Conversely, implementing a component across several screens quickly reveals where a design rule is too specific to one mock-up.

The relationship between design and development was iterative. Screens informed the component structure, and implementation challenged the screens. Small differences are easy to draw but harder to justify when they require separate code paths. Variation therefore had to become intentional.

The brand book developed alongside this consolidation. It brought together the values, personality, tone of voice, typography, colors, icon principles, and product experience guidelines that had emerged through the previous months. Creating it forced decisions that individual screens could postpone and turned visual preferences into shared rules.

The brand identity can be summarized through a few qualities: clear, empathetic, and reliable. These qualities function as design criteria rather than promotional adjectives. Clarity requires an understandable hierarchy. Empathy means avoiding language and interactions that create unnecessary pressure. Reliability includes predictable navigation, legible states, and careful treatment of user data. A distinctive visual style is useful only when it supports these qualities.

A cautious look toward adaptive interfaces

One future direction being explored is an adaptive interface. It has not yet been implemented, and the details remain intentionally broad. The basic idea is that the presentation could respond to screen size, accessibility preferences, or explicitly chosen modes instead of showing the same density at all times.

However, adaptation creates a design risk. An interface that changes too freely can become difficult to learn and may reduce trust. Important navigation should remain predictable, and users should understand why a view has changed. Suggestions should remain reversible, and the full information should still be accessible. For this project, the most promising principle is therefore not an interface that constantly rearranges itself, but a stable structure with carefully limited adaptive areas.

If adaptation is intended to reduce cognitive load, it must not create new uncertainty. Sufficient contrast, consistent controls, and user agency remain more important than novelty. The underlying system has to be stable first.

What I learned from the process

Looking back at the period from March to August 2026, the design developed through three broad stages. The first established the functional structure through wireframes. The second introduced a strong but comparatively playful visual direction. The third refined that direction through collaboration, implementation, and feedback until the interface became calmer and more coherent.

The process showed me that refinement is not simply the act of making a design more polished. It often requires changing the criteria by which the design is judged. Early in the project, I focused strongly on whether the screens had personality. Later, I evaluated whether that personality supported orientation, readability, and trust. The final direction is not less designed than the first one. It is more selective about where design becomes visible.

Recurring feedback also proved valuable even with a small test group. The most important findings were fundamental issues such as text size and contrast. Repetition made them harder to dismiss as individual preference and turned them into priorities. The design collaboration added a dialogue between graphic expression and interaction requirements rather than a simple handover between disciplines.

The current design should not be understood as a finished public product. More testing will be necessary on real devices and across different display settings. Accessibility checks must become continuous rather than a final review, and the adaptive interface idea will require careful prototyping.

For now, the most important result is a clearer design foundation. The project has moved from a collection of functional screens toward a recognizable system with shared principles. It can remain personal without becoming visually noisy, and it can become more structured without losing its organic character.

The complete application is not ready to be revealed, but the development process already offers a useful lesson: a calm interface is not created by simply removing elements or choosing quiet colors. It is created by deciding what deserves attention, testing whether users can recognize it, and refining every visual choice until personality and clarity support each other.

The post Designing a Calm Planning Experience: From Wireframes to a Coherent Visual Identity appeared first on Mobile USTP MKL.

The app is still in development, and many of its final ideas are intentionally not public yet. For that reason, this article does not reveal the complete product concept or all planned functionality. Instead, it focuses on the development process so far: how the project evolved from a SwiftUI interface prototype into a more structured iOS application with custom data models, persistent storage, reusable components, and first steps toward external calendar integration.

At the beginning, the project was mostly visual and exploratory. The first question was not “Which database should this use?” or “How should synchronization work?” but “What should this feel like on a phone?” Since the app is meant to be used frequently and quickly, the interface had to be approachable without becoming decorative for its own sake. SwiftUI was a natural choice because it allowed fast iteration on layout, navigation, state, and component structure. Early work focused on core screens: a home view, overview pages, detail pages, and small reusable interface elements that could later become the visual language of the app.

One of the first lessons was that a planning app becomes complex faster than expected. Even if the user-facing idea sounds simple, the underlying structures are not. A calendar item is not just a title and a date. It may have a start and end time, an all-day state, a location, notes, tags, a source, an editability status, and possibly a connection to another system. A task is also more than a checkbox. It can belong to a list, have a due date, include notes, be marked as important, be connected to a reminder, or later need rules for rescheduling. Reminders introduce yet another rhythm, because they are not exactly tasks and not exactly events. They sit somewhere between intention and interruption.

Because of that, the project moved relatively early from screen-building into model-building. Separate structures were created for calendars, events, lists, tasks, reminders, external sources, and calendar connections. This was an important shift. Instead of letting the UI define the data informally, the data model started to define what the interface could reliably express. Each object needed an identity, needed to be encodable, and needed to be flexible enough for future features without becoming vague. This part of the process was less visually exciting than building screens, but it made the rest of the application much more stable.

The central data layer became an observable store that holds the current calendars, events, lists, tasks, reminders, and external connections. This store is used throughout the SwiftUI views via environment injection, which keeps the individual screens relatively focused. A home screen can ask for visible calendars, upcoming events, or incomplete tasks without owning all the logic itself. Detail pages can receive a selected object and rely on shared update and delete methods. This architecture is still lightweight, but it creates a clear boundary between application state and presentation.

A useful turning point was implementing filtering and derived data. Once there were multiple entities in the store, the app needed answers to questions such as: Which events belong to this calendar? Which tasks belong to this list? Which events are upcoming? Which tasks are incomplete and still relevant? These may sound like small helper functions, but they changed how the app could be built. Instead of each screen duplicating filtering code, the store became the place where the application’s understanding of its data lived. That made the UI easier to read and helped reduce inconsistencies between screens.

Another major step was persistence. In early prototypes, sample data is enough. It helps with layout and gives the app something to display. But a planning app cannot remain a prototype for long if data disappears every time it restarts. The current version stores a snapshot of the application data as JSON in the app’s documents directory. The snapshot includes the core collections and can be loaded again when the app starts. The saving process also keeps a backup file, so the app has a fallback if the primary file cannot be read.

This persistence system is intentionally simple. It is not yet a large database layer, and that is partly deliberate. At this stage, JSON-based persistence makes the app easier to inspect, debug, and evolve. The project is still changing, and a lighter storage approach gives more freedom while the domain model continues to settle. At the same time, the persistence layer is separated from the store, so replacing or extending it later would not require rewriting the entire UI. This is one of the recurring themes of the project: avoid overengineering too early, but create enough structure that future changes do not become painful.

Autosave introduced its own design questions. A planning app should not require the user to manually save after every small change. The current approach listens for changes across the main collections and saves the current snapshot after a short debounce. This means the app can react naturally to edits while avoiding excessive file writes. It also means the development process had to account for state changes that are not user edits, such as loading persisted data at launch. Small flags and guard conditions became necessary to prevent the app from immediately saving over freshly loaded state or treating internal setup as user activity.

The interface also evolved significantly during this phase. The app now has a clearer structure of pages and components: overview views, detail views, card components, a navigation bar, headers, picker panels, floating action controls, and shared form elements. This componentization was not just about cleaner code. It also helped the app develop a consistent interaction style. Planning tools can easily become cluttered because they contain many object types and many possible actions. Reusable components make it easier to keep the experience predictable.

One example is the creation flow. Adding something new should not feel like entering a completely different app. The current implementation uses a shared sheet for creating or editing different item types. It supports modes for events, tasks, and reminders, with separate draft objects and validation. This draft-based approach is important because forms are temporary by nature. A user can open a sheet, make changes, switch context, cancel, or save. Keeping draft state separate from the saved model avoids accidental writes and makes validation clearer.

The form system also revealed how much detail is hidden inside “simple” input. Dates, times, optional fields, associations with calendars or lists, tags, icons, and reminder relationships all require careful handling. If these concerns are spread directly across the view code, the form quickly becomes difficult to maintain. By separating drafts, form rows, picker state, and saving logic, the app gained a structure that can grow without turning every new field into a cascade of fragile changes.

Design-wise, the project has been moving toward a custom visual identity rather than relying entirely on default iOS components. Custom fonts, color assets, icons, rounded shapes, and card components give the app a more personal tone. This is not only aesthetic. For a planning tool, visual hierarchy matters. The user should be able to distinguish calendars, lists, upcoming items, actions, and details quickly. Colors and cards are not decoration here; they carry information and help reduce cognitive load.

At the same time, building a custom interface in SwiftUI requires restraint. It is tempting to make every component unique, especially in a project that has a strong visual direction. But the more custom the interface becomes, the more responsibility the developer takes on for spacing, accessibility, responsiveness, and consistency. This has been one of the practical challenges of the project: finding the balance between a distinctive interface and a maintainable one. The current component structure is an attempt to make that balance explicit.

The most technically demanding part so far has been external calendar integration. Local planning data is one thing; synchronizing with external systems is another. The app now contains service layers for Apple Calendar and Google Calendar, as well as a synchronization service that imports events into the app’s own model. This required thinking about authorization, external identifiers, read-only versus editable sources, date ranges, mapping between API objects and local models, and what should happen when external events change or disappear.

Apple Calendar integration uses EventKit and must deal with platform-specific permission states. On newer iOS versions, access levels are more precise, so the app has to request and verify the correct kind of calendar access. The service can list available calendars and load events within a selected time range. These events are then mapped into the app’s internal event model, preserving information such as title, location, notes, URL, start and end date, all-day status, external identity, and sync metadata.

Google Calendar integration is different because it goes through Google Sign-In and web API requests. This required handling OAuth scopes, restoring previous sign-in sessions, refreshing access tokens, making authenticated requests, decoding calendar lists and event responses, and converting Google’s date formats into local date values. All-day events need special handling because calendar APIs often represent them differently from timed events. These are the kinds of details that are easy to underestimate before implementation begins.

The synchronization layer sits above the individual provider services. It loops through configured external calendar connections, loads events for each connection, imports them, tracks which external IDs were seen, updates sync timestamps, and reports failures. The store then upserts imported events instead of blindly appending them. This prevents duplicates and creates a place to handle conflicts. If a local event has pending changes and an external version arrives, the app can mark the situation as a conflict rather than silently overwriting data. Even though the full synchronization story is not finished, the current structure already reflects a key principle: user data should be treated carefully.

This was one of the biggest conceptual lessons of the project. Synchronization is not just a technical feature. It is a trust feature. If users put their plans into an app, they need confidence that the app will not lose, duplicate, or unexpectedly modify important information. That means the code has to represent uncertainty. It needs states such as local-only, synced, pending local changes, conflict, or deleted externally. These states are not glamorous, but they are what make the difference between a demo and a tool people might rely on.

Another lesson was that the app’s “domain” became clearer through implementation. At first, calendars, lists, tasks, and reminders may seem like familiar categories. But once they are modeled together, their relationships become more interesting. Some items belong to collections. Some can be associated with time. Some can be completed, others can only pass. Some are imported from outside and should not be edited locally. Some may later need richer rules. The development process has therefore been partly technical and partly analytical: understanding what each object means in the system.

The current prototype also includes several navigation paths: a home view with upcoming information, calendar overviews and detail views, list overviews and detail views, event and task detail screens, and setup flows. This breadth created a new kind of challenge. Once the app had more than one or two screens, consistency became harder. A change in the model might affect a card, a detail page, a form, and a preview all at once. This is where reusable view components started to pay off. They made the app feel less like a set of separate screens and more like one coherent product.

The project is still in an active development stage. There are visible signs of ongoing refactoring: components have been moved into clearer folders, global elements have been separated from list-specific and calendar-specific components, and some older file paths are being replaced by a more organized structure. This is a normal and healthy part of development. Early prototypes often grow organically. At some point, the structure has to catch up with the idea. The important part is not to make the architecture perfect immediately, but to keep improving it when the project’s shape becomes clearer.

Looking back, the development so far can be described in phases. The first phase was interface exploration: building enough screens to understand the experience. The second phase was domain modeling: defining the objects the app actually needs. The third phase was state and persistence: making the app remember and update data reliably. The fourth phase was integration: connecting the local world of the app with external calendar systems. The current phase is consolidation: refining components, improving flows, reducing duplication, and preparing the project for more advanced behavior.

For a student or early-stage software project, this progression is valuable because it shows how practical software development rarely follows a perfectly linear plan. The app did not begin with a complete architecture diagram and then simply fill in the pieces. Instead, each implementation step revealed the next architectural need. A form revealed the need for drafts. External calendars revealed the need for source metadata and sync states. Autosave revealed the need to distinguish loading from editing. Reusable cards revealed the need for stronger model relationships. The architecture emerged through contact with the problem.

There is also a broader lesson about building products that are not ready to be fully disclosed. It can be difficult to talk about a project publicly when the most exciting parts are still private. But not every development story has to reveal the final product. It is possible to discuss the engineering process, the technical decisions, the mistakes avoided, and the problems encountered without giving away the complete concept. In some ways, this is more useful for an informatics audience. The real value is not only in what the app will eventually do, but in how the system is being shaped to make that possible.

The next steps will likely focus on stability, refinement, and careful expansion. The persistence system will need to remain reliable as the data model grows. Synchronization will need more testing, especially around conflicts and edge cases. The interface will need continued polishing across different device sizes and user scenarios. Some flows that currently exist as early implementations will need to become more robust. And as the app moves closer to a publishable version, privacy, permissions, error handling, and user trust will become even more important.

What makes this project interesting is that it sits at the intersection of design, data modeling, and everyday behavior. A planning app is not just a technical container for events and tasks. It is a tool that asks to be invited into a user’s routine. That creates a high bar: the app has to be useful without being noisy, structured without being rigid, and personal without becoming confusing. Reaching that balance takes iteration.

So far, the development has already moved beyond a simple prototype. The app has a working SwiftUI foundation, a growing design system, structured models, persistent local data, reusable creation flows, and initial external calendar synchronization. More importantly, it has a clearer sense of direction. The final product is not ready to be revealed yet, but the development process has already shown what kind of challenge this is: not merely building screens, but building a coherent planning environment one careful layer at a time.

The post Building a Personal Planning App: From Interface Idea to Data-Driven iOS Prototype appeared first on Mobile USTP MKL.

Working in event management and also as staff during some of Austria’s biggest festivals, you start noticing some problems when it comes to registration of your clients: The company I currently work with (Adrenalin Company) specialises in the renting and operation high-thrill event tools that have certain risks associated to them in the event of misuse. Therefore, participants are required to sign so called liability exclusion disclaimers before attending.

The problem

Solution

Clients can read the liability exclusion disclaimer and sign it easily using their smartphone. Not only does this reduce the need for printed forms, but it also allows all participants to sign simultaneously, reducing overall wait time. After filling out and submitting the form, the participants are given a personalised QR-code that contains all the relevant information for us organisers.

Future

In future versions of this tool, the website would display the information in the system-used language, making it more accessible. The submitted information would be stored securely on a dedicated server for the legally required duration. On the other hand, there is a need to develop a specialised QR-code scanner application, that can read the participants codes and cross check them with the database in order to check their validity.

All in all, a user would first scan the QR-code on the poster and read, sign and submit the disclaimer. Then they would go to the event booth, where a staff member would scan each participant’s personalised code to verify its validity before they can enjoy the attraction.

Disclaimer: This project is not associated with BAGJUMP in any way. It is a purely academic student project, created for educational purposes only.

Link to the website: https://karavam.github.io/QR-Code-Website/

The post Print2Mobile Event registration tool appeared first on Mobile USTP MKL.

My idea was to create a virtual museum that can be accessed via QR codes printed on ads displayed directly in the stations. This way, people can learn about the station’s history while waiting for the train, riding it, or exploring the station. The aim is to make the project appealing not only to tourists but also to locals.

For my poster and prototype, I chose Karlsplatz Station as an example because it has a fascinating history and is notoriously difficult to navigate due to its many levels and countless exits.

The slogan on the poster plays with the phrase “finding out”, which not only refers to literally finding a way out of the complex passages and levels of Karlsplatz, but also to discovering the station’s history. The language is English because many tourists pass through Karlsplatz every day. When the campaign is implemented for other stations, such as Seestadt, which is mainly used by locals, a German version of the poster would make more sense. This particular poster could be displayed not only on the platforms but also near the exits, as the advertisement directly references that scenario.

After scanning the QR code, the content page for Karlsplatz opens. It contains four paragraphs focusing on the history, construction, and current role of Karlsplatz, supported by relevant images. There is also an option to listen to the content, the audio version should not exceed five minutes to keep the information concise and engaging. The language can be changed as well.

If you’re interested in the history of other stations, you can visit the station overview and search for them. There is also a map where you can check out your surroundings and nearby stations. In the “More” section, there could be items such as the imprint, data policies, contact information, or links to other services and apps provided by the City of Vienna.

This Project is just a concept and not affiliated with Wiener Linien in any way. It is a purely academic student project, created for educational purposes only. No financial support, sponsorship, or compensation has been received from Wiener Linien or any other company. Any use of names or logos is solely for demonstration purposes within the prototype.

Sources:

• Person auf dem Poster: Foto von Nathan Dumlao auf Unsplash
• Karlsplatzbild: Foto von Shery Arturova auf Unsplash
• Karte von https://www.openstreetmap.org/#map=15/48.18031/16.36414
• Baustelle Karlsplatz Bild: https://newsv2.orf.at/stories/2424487/2425558/
• United kingdom icons created by Freepik – Flaticon: https://www.flaticon.com/free-icons/united-kingdom

Other Projects

Swiva is a mobile app for saving ideas, places, recipes and activities from TikTok, Instagram, Maps and the web, and actually turning them into plans.

The post Print2Mobile | TrackBack Vienna – Get to know Viennas Subway System (Print2Mobile Project) appeared first on Mobile USTP MKL.

We’ve all been there, standing in front of the fridge or in the supermarket aisle not knowing what to cook. Meanwhile, tons of perfectly good food end up in the trash every day.

Dishcovery not only inspires creativity in the kitchen — it makes sustainability simple, digital, and rewarding.

This project is not affiliated with BILLA or the REWE Group in any way. It is a purely academic student project, created for educational purposes only. No financial support, sponsorship, or compensation has been received from BILLA or any other company. Any use of names or logos is solely for demonstration purposes within the prototype.

iPhone design by Luis Orea
Icons designed by Kryston Schwarze https://coolicons.cool/
Illustrations/Icons designed by Freepick www.freepik.com

Other Projects

Swiva is a mobile app for saving ideas, places, recipes and activities from TikTok, Instagram, Maps and the web, and actually turning them into plans.

The post Print2Mobile | Dishcovery appeared first on Mobile USTP MKL.

Nativescript – eine kurze Vorstellung

Mit NativeScript, das 2015 auf den Markt kam, wurde ein Framework präsentiert, das plattformübergreifende mobile Apps ermöglicht und zugleich direkten Zugriff auf die nativen Funktionen von Android und iOS bietet. Seit dessen Einführung wird es kontinuierlich weiterentwickelt und hat sich zu einer stabilen Lösung für die App-Entwicklung etabliert. NativeScript erlaubt es, Apps mit bekannten Web-Technologien wie JavaScript, TypeScript, Angular oder Vue.js zu erstellen, wodurch der Einstieg für Web-Entwickler besonders einfach ist. Gleichzeitig werden die UI-Komponenten direkt nativ gerendert, was eine nahezu maximale Leistung gewährleistet. Ein Großteil des Codes kann zwischen Android und iOS weiterverwendet werden, wodurch Entwicklungszeit und -kosten reduziert werden. Damit kombiniert NativeScript die Vorteile plattformübergreifender Entwicklung mit direktem API-Zugriff und nativer Performance.

Mit diesem Wissen im Gepäck gelang es mir meine Erstentwicklung als reine WebApp in Angular ohne grundlegenden Neuanfang im nativen Bereich durchführen. Das hat mir die Möglichkeit eröffnet viele Teile der ursprünglichen Angular-Programmierung in eine App zu übertragen, auch wenn dies mit einer gewissen Komplexität einherging.

Von einer Web-App zu einer nativen App

Der Wechsel von der ursprünglichen Angular Web-App zu einer nativen App mit NativeScript stellte einen entscheidenden Entwicklungsschritt dar. Während die erste Version ausschließlich im Browser funktionierte und auf klassische Web-Komponenten ausgelegt war, verlagerte sich der Fokus nun auf die mobile Nutzung, native Performance und eine tiefere Integration in die jeweilige Plattform. Diese Veränderung erforderte nicht nur technisches Know-how, sondern auch ein grundlegendes Umdenken im App-Design. Die Benutzeroberfläche musste für mobile Endgeräte neu konzipiert werden, denn alleine responsive Layouts reichten nicht mehr aus. Stattdessen waren eine intuitive Navigation, Gestensteuerung und schnelle Ladezeiten gefragt. Technisch konnten viele Angular-Module und Services zwar grundsätzlich übernommen werden, jedoch waren umfangreiche Anpassungen notwendig, insbesondere beim Routing, der Datenbindung und dem Zugriff auf systemnahe Funktionen wie dem Dateispeicher.

Optimierter Suchalgorithmus

Der ursprüngliche Suchalgorithmus stellte einen klaren Engpass dar, da jede Filteranfrage direkt an die externe API gesendet wurde. Das führte zu langen Ladezeiten und unnötiger Netzwerklast.

Mit dem neuen, optimierten Ansatz werden die Rezeptdaten nun beim Start der Anwendung automatisch aus der API geladen und in die lokale Datenbank geschrieben. Die Suche erfolgt anschließend vollständig serverseitig über diese Datenbank, wodurch Abfragen deutlich schneller und stabiler laufen. Gleichzeitig bleibt die Filterlogik flexibel: Nutzer:innen können nach Kategorie, Alkoholgehalt und Zutaten suchen, ohne dass alle Kriterien zwingend gesetzt sein müssen.

Die “Signature”-Drinks

Dieses neue Feature bietet dem/der User:in die Möglichkeit, sich seinen/ihren Drink (Cocktail) selbst nach eigenen Wünschen zusammenzustellen. Diese Drinks in Form von Rezepten werden entsprechend gekennzeichnet und sind mit dem/der Ersteller:in verknüpft. Die Datenspeicherung erfolgt in der selben Tabelle, wo die Drink Rezepte der API abgespeichert sind. Nach dem Anlegen eines “Signature”-Drinks stehen dem/der Ersteller:in die Möglichkeit zur Verfügung den Drink . Hier ein Blick in die App (Bild folgt):

Weitere Features/Verbesserungen

Redesign

Mit dem Wechsel von einer WebApp auf eine native Mobile-App wurde das bestehende Design nicht vollständig neu entwickelt, sondern gezielt modernisiert und an mobile Nutzungsszenarien angepasst. Der Fokus lag dabei auf einer klareren visuellen Struktur, einer verbesserten Bedienbarkeit sowie einem konsistenten Erscheinungsbild über alle Ansichten hinweg.

Ein wesentlicher Schritt war die Umstellung des UI-Designs auf das Utility-First-Framework Tailwind CSS, das eine deutlich effizientere Gestaltung und höhere Flexibilität bei der Komponentenentwicklung ermöglicht. Dadurch konnten wiederkehrende Layouts vereinheitlicht, Abstände und Typografie präzise gesteuert und das gesamte Erscheinungsbild minimalistischer und moderner gestaltet werden.

Zutaten Suchfunktion

Bisher musst man sich durch eine lange Liste von Zutaten “quälen” – mit einem neuen Suchfeld bei den Zutaten wurde dies nun deutlich vereinfacht.

Herausforderungen im Entwicklungsprozess

Anbei zwei wesentliche Herausforderungen, die sich während der Entwicklungsarbeit zunehmend herauskristallisiert haben:

Die mobile Umsetzung von MixMatch mit NativeScript und Angular brachte einige technische und strukturelle Herausforderungen mit sich. Der Umstieg von der bisherigen Angular-Webumgebung auf NativeScript erforderte eine Einarbeitung in neue Syntaxkonzepte und native UI-Komponenten. Viele Layouts und Funktionen ließen sich nicht direkt übernehmen, sondern mussten gezielt an mobile Anforderungen angepasst werden. Zudem NativeScript auch noch ein sehr “junges” natives Framework ist und die Dokumentation derzeit noch nicht als allzu ausgereift erscheint.

Gleichzeitig wurde deutlich, dass Teile des bestehenden Codes, insbesondere im Hinblick auf Wartbarkeit und Performance auf mobilen Geräten, zu komplex aufgebaut waren. Um dem entgegenzuwirken, habe ich z. B. Übersetzungen in separate Lokalisations-Files ausgelagert, anstatt sie direkt im Code zu halten. Auch die Datenverarbeitung wurde angepasst: Statt verschachtelter Aufrufe zu der thecocktaildb API erfolgt die Filterung nun über eine lokale Datenbank, nachdem alle Daten der externen API einmalig gespeichert wurden.

Resümee mit Ausblick

Das Projekt stellte in mehrfacher Hinsicht eine wertvolle Lernerfahrung dar – insbesondere durch den mutigen Schritt, mit NativeScript in ein für mich völlig neues Framework einzusteigen. Dieser Ansatz bot die Gelegenheit, die Stärken und Schwächen der Plattform unmittelbar kennenzulernen: Auf der einen Seite die hohe Flexibilität, die tiefe Integration nativer Funktionen und die Möglichkeit, moderne Frontend-Technologien wie Angular und Tailwind zu kombinieren; auf der anderen Seite aber auch die typischen Herausforderungen eines jungen Frameworks – etwa eingeschränkte Dokumentation, komplexe Build-Prozesse und teils unerwartete Kompatibilitätsprobleme.

Gerade dieser direkte Umgang mit den Schattenseiten und positiven Aspekten des Frameworks hat jedoch den größten Lerneffekt gebracht. Es entstand ein tieferes Verständnis für mobile App-Architekturen, die Bedeutung einer sauberen Code-Struktur.

Auch nach Abschluss dieser Entwicklungsphase bleiben einige naheliegende Erweiterungen vorstellbar, die sich mittelfristig umsetzen lassen. Dazu zählt etwa eine Kommentarfunktion, mit der Nutzer:innen direkt Rückmeldung zu einzelnen Drinks geben oder sich austauschen können. Ebenso wäre es denkbar, die „Signature Drinks“ für andere sichtbar zu machen. Mit der individuellen Möglichkeit, eigene Rezepturen anderen Usern/Userinnen sichtbar zu machen, können persönliche Rezeptideen einem weiten Publikum präsentiert werden.
Ergänzend ließe sich eine einfache Einkaufsliste integrieren, in der fehlende Zutaten gesammelt und als Liste exportiert werden könnte. Diese funktionalen Erweiterungen würden, wie üblich, Hand in Hand mit weiterem Bugfixing, Code-Optimierungen und kleineren UI-Verbesserungen erfolgen, um die App sowohl technisch als auch inhaltlich weiter zu stabilisieren, der Benutzerfreundlichkeit hin zu optimieren und auszubauen.

Beitragsbild: dieses wurde mittels Einsatz von KI erzeugt

The post Projekt SS25 | MixMatch (Fortsetzung) appeared first on Mobile USTP MKL.