I chose this topic because before writing this blog, I honestly didn’t really understand how websites actually get found on Google. I also didn’t know what you can do to improve visibility or why some websites show up everywhere while others basically don’t exist in search results.

A lot of people think that once you build a website and put it online, it automatically appears on Google. But that’s not how it works. Search engines first need to find the website, analyze it, and add it to their system. Only after that it can show up in search results.

What does indexing mean?

When a website goes live, it does not immediately appear on Google. Instead, search engines use automated programs called crawlers. These crawlers constantly scan the internet, follow links from page to page, and collect information from websites.

When they visit a page, they read the content and store it in a huge database called the index. You can imagine this index like a giant digital library. If your website is not inside this library, Google simply does not know it exists.

Why being online is not enough

Just putting a website online is not enough to be visible. Many websites stay invisible because search engines cannot properly find or understand them. This often happens when the technical structure is weak or when the website is not clearly organized for crawlers.

Even a well-designed website can have almost no traffic if it is not technically optimized for search engines.

SEO and why it matters

SEO, which stands for Search Engine Optimization, plays a very important role here. It is one of the main factors that decides how visible a website is on Google.

SEO is influenced by things like page titles, high-quality content, fast loading speed, and especially mobile optimization. Today we live in a “mobile first” world, which means websites are mainly evaluated based on how they work on mobile devices.

Keywords are also a big part of SEO. These are the search terms people type into Google. To make a website visible, these keywords need to be used naturally in the content. But it is not about adding random words everywhere. It is much more important to understand the search intent behind them. People usually search either for information or for products and services, and the content should match that.

Local visibility and Google Business Profile

For local businesses, regional visibility is extremely important. A Google Business Profile helps companies appear in local search results and gives users key information like opening hours, address, contact details, and reviews.

For small and medium businesses especially, this can make a huge difference because many customers search for services “near me”.

Security also affects ranking

Website security is another important factor. Websites should always run on HTTPS because Google prefers secure connections. If a website does not have an SSL certificate, it can not only reduce user trust but also negatively affect rankings.

It is also important to keep platforms like WordPress updated. Outdated plugins or insecure configurations can cause performance issues and even create security risks.

Google Search Console as a key tool

One of the most important tools in technical SEO is Google Search Console. It helps you control and monitor how your website appears on Google.

With this tool, you can submit your website directly to Google, upload a sitemap, and request indexing for specific pages. It also shows whether there are crawling issues, which pages are already indexed, and which search terms bring users to your website.

For new websites, this tool is especially important because it speeds up the whole indexing process and gives clear insights into visibility.

Traffic and what happens after indexing

Once a website is indexed, the next step is improving traffic. Getting indexed is a big milestone, but real success starts when people actually visit the website.

There are many ways to increase traffic. A big part of it is networking and simply getting the website out into the world. Sharing it on social media helps a lot, as well as using business cards, flyers, or even adding the website to directories and online listings.

The more places a website appears, the more signals it sends to search engines that it is relevant and active.

Conclusion

Before my first real website project, I thought building a website was mainly about design and development. I assumed that once a site is online, it will automatically be found.

But in reality, it is completely different. Visibility depends on many factors working together, like indexing, SEO, technical quality, content, and external signals.

A website is not just something you build once. It is something you need to optimize and maintain if you want it to actually be seen.

And yes, traffic matters a lot. Google basically thinks: “If nobody visits it, is it even worth showing it?” So the more real users interact with a website, the better it performs in search.

So, in true “help a student”. I’d really appreciate if you could do me a small favor and click on the links below. No pressure… but Google definitely loves attention.

Swiva: https://swiva.app/
RKZ Metall Design GmbH: https://www.rkz-design.gmbh/

Sources:

https://webgo.de/blog/bei-google-gefunden-werden

https://www.media-company.eu/blog/website-bekannt-machen-bei-google

https://www.peaknetworks.ch/blog/wie-wird-meine-website-in-google-angezeigt

https://developers.google.com/search/docs/fundamentals/get-on-google?hl=de

https://webdirwas.at/website-fuer-google-sichtbar-machen/

https://www.domainion.at/suchmaschineneintrag

The post Why Your Website Doesn’t Show Up on Google (And How to Fix It) appeared first on Mobile USTP MKL.

In short: scroll less, experience more.

The Problem and Project Process

When we started this project, we only had a early prototype and not really a clear or strong brand identity. Since we only had one project semester, we also didn’t have the time to go deep into branding and design from the beginning. As a result, things felt a bit inconsistent and not fully thought through yet.

So I set myself the goal to change exactly that.

I started by creating a proper style guide and reworking both the logo and the overall brand identity. After that, I worked in an iterative design process. That basically means I constantly moved between creating ideas, building mockups, improving them, and then discussing everything with my team. Feedback played a important role here.

On top of that, I also designed the preview visuals for the App Store and Google Play Store, making sure the first impression of Swiva feels clean and engaging.

Tools and Technologies

For the design work, I used a mix of different tools. Figma was the main tool for designing all the app screens and building the overall structure of the product. For image editing and vector work, I used Adobe Creative Cloud.

To speed up the workflow and find the right visual elements, I also used platforms like Magnific and Envato Elements for icons, illustrations, and other design assets.

What I Learned

Besides the design part, there was also a lot of organizing and planning involved in this project. My team and I used Swiva as part of our course Tun/Forschen/Gründen, but also for different competitions and our project exhibition.

Because of that, I naturally improved my time management and learned how important it is to stay structured when working on a longer project with multiple goals at the same time.

From a design perspective, working with a style guide really changed how I approach design. Instead of just designing based on feeling, I now have a clear system that helps me stay consistent. It also made it much easier to improve the quality of the design over time, since everything follows the same direction.

Overall, I would say my design skills improved a lot during this process, especially in terms of consistency and visual thinking.

Conclusion and Future Steps

Next up, we will take part in the Interactive Digital Media Student Contest in Romania. After that, we’ll present Swiva at our project exhibition, and in the winter semester we will pitch it for the pre-incubator program.

At the same time, we are currently working on a full brand book. The goal is to clearly define our design principles and values, so we always keep a consistent direction as the project continues to grow.

Try Swiva

If you’re curious, you can check out Swiva here:
https://swiva.app/

Or download it soon on the App Store or Google Play Store.
https://swiva.app/download

The post PROJECT | Redesigning Swiva: Building a Clear and Consistent Design System appeared first on Mobile USTP MKL.

Mit ergo4All soll eine digitale Lösung entwickelt werden, die ergonomisches Wissen und konkrete Anpassungsvorschläge allen Menschen zugänglich macht – unabhängig von Alter, körperlichen Voraussetzungen oder digitaler Kompetenz. Innerhalb der App steht dabei das Ziel im Vordergrund, individuelle Empfehlungen für gesundes Arbeiten und Alltagsbewegungen leicht verständlich und barrierearm bereitzustellen.
Je nach, welches Szenario (Heben/Tragen, etc.) man in der App wählt, bewertet die KI (gestützt auf maschinelles Sehen und den anerkannten RULA‑Score) Körperhaltungen aus einem kurzen in Echtzeit dokumentierten Video. Anschließend liefert sie dem/der NutzerIn leicht verständliche Hinweise zur Verbesserung der Haltung. Alle Daten werden lokal auf dem Gerät verarbeitet, daher findet keine Cloud‑Speicherung oder Tracking statt.

Zielsetzung

Am Anfang meiner Projektmitarbeit umfassten meine Aufgaben das Redesign bestehender App-Screens sowie die Erstellung neuer Screens mit entsprechender Navigation auf Basis des damals erstmalig überabeiteten Figma-Mockups. Dieses ist hier zu sehen:

Zusätzlich war ich beauftragt die Lokalisierung von Texten, Buttons und co. für Deutsch und Englisch über ein eigenes Lokalisierungsfile vorzunehmen. Im weiteren Verlauf wurde ich gebeten, mir auf einem eigenen GIT-Branch anzuschauen, wie die App für IOS gebuildet werden kann, um lauffähig zu sein. Zum Abschluss lag die Verantwortung für den Aufbau des Onboardings gemäß eines vorab abgestimmten Konzepts bei mir.

Durchführung

In ersten Schritten wurde ich von Dipl.-Ing. Ramon Brullo BSc technisch in die App eingeführt. Dabei wurde die klare Code-Struktur der App erklärt. Es handelt sich hierbei um eine Flutter-App, dessen Hauptsprache die Programmiersprache Dart ist

In den ersten Schritten wurde ich von Dipl.-Ing. Ramon Brullo, BSc technisch in die App eingeführt, wobei insbesondere die klare Code-Struktur einer Flutter-App (Programmiersprache Dart) erläutert wurde. Die Lokalisation erfolgt über ein JSON-File, die Codeverwaltung über GIT mit Sub-Branches und einer regelmäßigen Release-Pipeline. Die Commits orientieren sich am Standard der Conventional Commits, die wiederum die Release-Pipeline anstößt.
Ich nahm bei den fast jeden Dienstag stattfindenden Meetings zwischen unserem Projektteam und TU-KollegInnen teil, in denen Status und Fortschritte abgestimmt wurden. Anfangs lag mein Schwerpunkt auf der App-Lokalisation und dem Verständnis des Codes, bevor ich am Frontend größere Änderungen vornahm und regelmäßig Commits einbrachte. Für design-relevante Themen war Vivian Seidl BSc zuständig, mit der ich mich eng abstimmte.

Ein größeres Vor-Ort-Meeting Mitte Juni diente dazu, die Planung bis in den Herbst hinein gemeinsam mit den TU-KollegInnen festzulegen. Zudem habe ich mir in Flutter angeschaut, wie man einen iOS-Build macht und am Onboarding beteiligt. Das Frontend des Onboarding übernahm ich ganz, während Ramon die Backend-Einbindung in den Appflow übernahm.

Ergebnisse

Nachdem das Redesign abgeschlossen und alle fehlenden Screens ergänzt wurden, gliedert sich das App-Layout nun folgendermaßen (der Onboarding-Prozess, welche erst vor kurzem in der Form dazu kam, wird unterhalb erläutert):

Die App startet beim erstmaligen Öffnen mit einem Welcome-Screen samt Sprachwahl, bevor der/die NutzerIn nach einem Onboarding ins Hauptmenü gelangt. Von dort aus lassen sich direkt allgemeine Tipps zur Ergonomie-Themen oder konkrete Szenarien auswählen. Über den Tipps-Selection-Screen geht es in detaillierte Anleitungen zur Körperhaltung. Wählt man ein Szenario, bekommt man eine kurze Szenariobeschreibung und folgt der Aufnahmefunktion, mit der die eigene Haltung erfasst wird. Anschließend werden im Ergebnis-Screen eine Übersicht und Detailbewertungen angezeigt, inklusive spezifischer Analysen einzelner Körperbereiche. Durch das Redesign sind sind alle Texte lokalisiert und das Screen-Layout Großteils einheitlich.

Nachdem der/die UserIn die Sprache vorselektiert hat, startet in der gewählten Sprache beim erstmaligen Betreten in die App ein durchstrukturiertes Onboarding. Zuerst wird auf die Privatsphäre hingewiesen und erklärt was mit den gesammelten App-Daten passiert. vordem die App kurz und prägnant vorgestellt wird.

Nachdem die Sprache ausgewählt wurde, startet beim ersten App-Betreten ein klar strukturierter Onboarding-Prozess in der gewählten Sprache.

1. Privatsphäre – Zunächst wird erklärt, dass die App komplett offline funktioniert, keine Cloud und kein Tracking verwendet und alle Daten lokal am Gerät bleiben.
2. App-Übersicht – Danach folgt eine kurze Einführung, die den Zweck der App verständlich darstellt.
3. AGBs – Anschließend werden die Nutzungsbedingungen präsentiert, mit einem klaren Hinweis darauf, dass die Ergebnisse nur Informationscharakter haben und keine fachliche Beratung ersetzen.
4. Was ist Ergonomie? – Dieser Screen erläutert die Grundidee der Ergonomie und vermittelt, dass nicht das momentane Empfinden, sondern langfristige Gesundheit im Mittelpunkt steht.
5. Dein Nickname – Zum Schluss können NutzerInnen optional einen Spitznamen vergeben, um Ergebnisse leichter wiederzufinden.

Alle Texte der Onboarding-Screens wurden sorgfältig von einem Kollegen der TU Wien entwickelt, um Inhalte sprachlich präzise, leicht verständlich und zugleich den wissenschaftlichen Standard entsprechend.

Fazit und Ausblick

Bezugnehmend auf meine Vorkenntnisse im hybriden App-Development mit Flutter stellte sich dieses Projekt als sehr gewinnbringend für mich dar. Ich konnte mein Flutter-Wissen nicht nur auffrischen, sondern auch um neue technische Aspekte erweitern. Darüber hinaus erhielt ich durch meinen Teamkollegen Dipl.-Ing. Ramon Brullo, BSc wertvolle Einblicke in unterschiedliche App-Testansätze, deren Einsatzwahl und deren konkrete Umsetzung in Flutter.

Besonders hervorzuheben ist, dass mir Ramon auch das Konzept der Conventional Commits zeigte, das für mich völlig neu war. Ich konnte den Ansatz schnell nachvollziehen und habe diesen im Projekt selbstständig angewendet. Dadurch habe ich nicht nur die Struktur meiner Commits verbessert, sondern auch den Mehrwert von standardisierten Commit-Messages für Teamarbeit und Release-Prozesse erkannt. Ebenso waren die regelmäßigen Meetings und die enge Abstimmung im Team ein Mehrwert für mich. Sei es eine persönliche Weiterentwicklung im Hinblick auf Teamarbeit oder Projektorganisation.

Im Großen und Ganzen nehme ich aus dem Projekt 80 lehrreiche Stunden mit, in denen ich mein technisches Know-how im Bereich Flutter-Entwicklung erweitern, meine Arbeitsweise im Team verbessern und wertvolle praktische Erfahrungen in der koordinierten App-Entwicklung sammeln konnte.

Da es sich noch um ein derzeit laufendes Forschungsprojekt handelt, entspricht die aktuelle App-Version noch nicht der geplanten Veröffentlichung. Im Herbst werden noch einige zusätzliche Usability-Testings in Unternehmen durchgeführt, deren Ergebnisse in die finale Weiterentwicklung einfließen. Eine Veröffentlichung der App in die App-Stores ist noch im heurigen Herbst geplant.

Mehr zu dem Forschungsprojekt lesen? – https://research.fhstp.ac.at/projekte/ergo4all-ergonomie-fuer-alle

The post TFG | ergo4All Forschungsprojekt appeared first on Mobile USTP MKL.

Das Hauptziel des Forschungsprojekts besteht darin, mittels einer App klimafreundliches Verhalten zu fördern und passende regionale Aktivitäten (sogenannte Initiativen) zu präsentieren. Die App Erika soll informieren, durch spielerische Elemente motivieren und belohnen. Das Forschungsprojekt erfolgt am Beispiel der Region Waidhofen a/d Ybbs, weshalb auch eine Integration in die vorhandene Waidhofen-App vorgesehen ist.

In der App können Nutzer*innen an Initiativen teilnehmen, Aufgaben erfüllen und Belohnungen erhalten. Zusätzlich können sie Vorschläge für Initiativen machen und die von anderen bewerten.

Zielsetzung

Meine Aufgabe war es, ein funktionsfähiges CMS laut vorhandenem Prototyp umzusetzen. Dazu zählten sowohl die Umsetzung des Frontends als auch Anpassungen und Ergänzungen im bestehenden Backend. Das CMS sollte vor allem diverse Daten von Nutzer*innen, Initiativen etc. anzeigen, ein Login beinhalten und die Möglichkeit bieten, Inhalte für die App erstellen, bearbeiten und löschen zu können. Zudem sollten mit dem CMS PDFs generiert werden können, die für Initiativen und Belohnungen benötigt werden.

Vorgehensweise

Die genauen Funktionen des CMS wurden anfangs definiert und priorisiert, und später leicht angepasst. Zu Priorität 1 zählten vor allem die Authentifizierung, die Anzeige der verschiedenen Daten (Nutzer*innen, Initiativen und Belohnungsmöglichkeiten) und die Generierung von PDFs. Im nächsten Schritt lag der Fokus auf den Vorschlägen für Initiativen, die angezeigt und freigegeben werden können. Zum Schluss wurden die Funktionalitäten ergänzt, Initiativen anlegen, bearbeiten und löschen zu können.

Verwendete Technologien:

• Frontend: Low-Code-Framework Luisa, Vue.js und Axios
• Libraries für die PDF-Generierung (inkl. QR-Code): pdf-lib, qrcode und file-saver
• Prototyp: QuantUX
• Backend: Express Framework, Effect Library und Swagger

Während der Mitarbeit beim Forschungsprojekt teilte ich mir die Zeit selbst ein, machte mit dem Projektleiter Dipl.-Ing. Gernot Rottermanner vor allem separate Meetings aus und nahm vereinzelt am wöchentlichen Jour Fixe teil. Für das Frontend war ich allein zuständig, während ich beim Backend zusammen mit Dipl.-Ing. Ramon Brullo arbeitete, der vor allem die Funktionen für die App selbst und später das Erstellen und Bearbeiten von Initiativen umsetzte. Den Prototypen für das CMS hatte Dipl.-Ing. Gernot Rottermanner bereits entwickelt. Durch die Verwendung des Low-Code-Frameworks Luisa konnte ich das Design sofort übernehmen, mich auf die Funktionalität konzentrieren und musste in QuantUX nur noch an manchen Stellen Anpassungen vornehmen.

Ergebnisse

Hier können alle Initiativen eingesehen, bearbeitet und neue erstellt werden. Für jede Initiative lässt sich ein PDF und ein QR-Code generieren.

Auf dieser Seite kann eine neue Initiative mittels JSON erstellt und die Eingabe formatiert werden. Das Textfeld wird je nachdem, ob eine Initiative erstellt oder bearbeitet wird, mit einer Vorlage oder den richtigen Daten befüllt. Eine bestehende Initiative kann hier ebenso gelöscht werden.

Auf dieser Seite lassen sich alle eingereichten Ideen (Vorschläge für Initiativen) einsehen und freigeben, sowie alle Bewertungen der freigegeben Ideen nachsehen.

Die Benutzer:innen- und Einlösemöglichkeiten-Seite ähneln dem Rest. Auf ersterer werden alle Nutzer*innen inklusive ihrem Erstelldatum, der Anzahl der angemeldeten und teilgenommenen Initiativen und ihrem “Spielstatus” angezeigt. Auf zweiterer werden alle Einlösemöglichkeiten, sprich mögliche Belohnungen, aufgelistet. Für jede lässt sich ebenso ein entsprechender QR-Code und ein PDF generieren.

Retrospektive

Durch meine Mitarbeit bei Erika konnte ich meine Programmier-Kenntnisse erweitern und viele neue Technologien kennenlernen. Sowohl die komplette Backend-Struktur als auch das Low-Code-Framework Luisa waren neu für mich. Anfangs war das durchaus herausfordernd, doch schnell bekam ich einen Überblick und konnte alles wie geplant umsetzen. Die Verwendung von Luisa hat die Entwicklung des Frontends erheblich beschleunigt und es mir erlaubt, mich vor allem auf das Backend zu konzentrieren. Bei einfachen Projekten ist das Low-Code-Framework sehr praktisch, bei höheren Anforderungen wie z.B. responsive Tabellen stößt es jedoch an seine Grenzen. Insgesamt war das Projekt abwechslungsreich und ließ sich gut im Rahmen der vorgegebenen 80 Stunden umsetzen.

Link zum Forschungsprojekt: https://research.fhstp.ac.at/projekte/erika

The post TFG | Erika CMS appeared first on Mobile USTP MKL.

ABSTRACT

The increase in mobile device usage has driven the need for applications that work across various platforms. This paper explores the two primary approaches to mobile app development: native and cross-platform. Existing research shows that native development ensures high performance and user experience but requires more time and resources. In contrast, cross-platform development methods – such as web, hybrid, interpreted, and cross-compiled apps – streamline development through code reuse, though often at the cost of performance and functionality. However, as mobile technologies continue to evolve, research gaps remain, thus emphasising the need for updated studies to reflect the rapid technological advancements in this field.

1 Introduction

Nowadays, mobile phones have become a device that most people use every day, and the various types of smartphones on the market are almost as diverse as the people using them. Thus, developers intending to create an app need to make sure that it can run on different operating systems. By making an app available on as many mobile platforms as possible, the app’s market presence can be increased, which according to Delía et al. (2017) is vital, as the success of an app is tied to its popularity.

However, due to the numerous possibilities regarding programming languages, development tools, time-to-market demands, and more, the choice on how to make the app work on multiple platforms is not always easy (Delía et al., 2017), especially also because of the ever-changing and constantly evolving technologies (Karami et al., 2023).

There are two different approaches to app development, which will both be discussed in this paper: native and cross-platform development. Both of them have their advantages and disadvantages, which all need to be considered when choosing between the available app development frameworks (Karami et al., 2023). The goal of this paper is to examine and compare other researchers’ findings on app development approaches and to identify gaps that need to be addressed through future research.

2 Types of App Development

2.1 Native App Development

When developing mobile applications natively, a development project is created and worked on for each platform, which uses the platform-specific languages (Delía et al., 2017), such as Java or Kotlin for Android and Swift for iOS (Koram & Garg, 2023; Suri et al., 2023). Thus, when wanting to distribute an app to different platforms, the same app has to be developed multiple times (Koram & Garg, 2023). Since a separate app needs to be developed for each platform, the development and maintenance of apps costs more and demands more effort (Delía et al., 2015);  due to little code reuse, it is very expensive and time-consuming (Suri et al., 2023).

However, these extra costs also have their advantages: native app development allows developers to directly access native platform functionalities, such as the camera, GPS, and other sensors (Delía et al., 2017; Ebone et al., 2018; Koram & Garg, 2023). Furthermore, according to Delía et al. (2017), a user does not need to be connected to the internet to be able to run a native application. Additionally, the researchers claim that native apps execute quickly and it is possible for them to run in the background. Generally, Ebone et al. (2018) believe that native apps provide the best performance and user experience on their respective platforms. Patidar and Suman (2021) are of a similar opinion, since they state that native apps tend to allow for high performance and good user experiences. Koram and Garg (2023) also highlight the “significantly better performance” of native apps and their secure and robust user interfaces (p. 262). Because of their performance and fast execution time, native apps typically have a higher ranking in app stores, meaning they have a “significantly higher level of user satisfaction” (Suri et al., 2023, p. 2).

When it comes to native applications in the academic field, Karami et al. (2023) evaluated 75 peer-reviewed conference and journal papers on different app development approaches and noticed that Android and iOS were the first and fifth most studied frameworks. The researchers believe this might be because half of the evaluated studies used a native app development framework as a baseline to compare cross-platform frameworks to.

2.2 Cross-Platform App Development

Cross-platform, or multi-platform, development uses a single code base which can be run on different mobile platforms (Delía et al., 2017; Ebone et al., 2018; Suri et al., 2023). Thus, the advantage of this development approach is the reduction of development effort, cost and time (Delía et al., 2017; Ebone et al., 2018; Suri et al., 2023) due to the code reutilisation (Delía et al., 2015). However, cross-platform apps are unable to provide the same performance and user experience as native applications (Suri et al., 2023).

According to Karami et al. (2023), the academic interest in cross-platform frameworks is advancing: Cordova appeared within 32 studies and is therefore the most studied multi-platform framework. However, Cordova, as well as Titanium, are also among the oldest cross-platform frameworks, as they were released in 2009. The newer frameworks include Xamarin, which was released in 2011, React Native, which came out in 2016, and Flutter, which was released a year later. In 2021, Flutter was very popular among developers (Koram & Garg, 2023). Karami et al. (2023) also found Flutter and React Native to have been the most popular multi-platform frameworks among developers in 2022, thus beating Ionic and Xamarin. 

Although the mentioned frameworks are all cross-platform, they can differ in how they work. There are multiple approaches to cross-platform app development, which will be elaborated on in the following subchapters.

2.2.1 Web Applications

Web applications are apps that are developed with HTML, CSS and JavaScript, and run in the browser (Delía et al., 2017; Koram & Garg, 2023). No installation is necessary, which means the distribution and updating of apps is easier (Delía et al., 2017; Koram & Garg, 2023), but it might make the application less attractive compared to native apps (Delía et al., 2015). Since only a browser with a connection to the internet is needed, the development is fast and easy, and the developer does not need to adapt to any specific platform (Delía et al., 2017).

On the downside, due to the client-server interaction via the internet, the response time and performance of the web app could be affected negatively (Delía et al., 2015), which could worsen the user experience (Delía et al., 2017). In addition to web apps being dependent on an internet connection most of the time, the type of browser may also affect the user experience (Koram & Garg, 2023). Furthermore, because of the security restrictions imposed on websites, web apps and their interfaces are limited when it comes to the use of native functionalities (Delía et al., 2015; Delía et al., 2017).

Nowadays, Progressive Web Apps (PWAs) aim to make web apps feel more like real apps, by even making them able to be run offline (LePage & Richard, 2024), which is why it would be interesting to further investigate how modern PWAs compare in terms of performance and usability.

2.2.2 Hybrid Applications

Hybrid applications rely on the use of web technologies, such as HTML, CSS and JavaScript, but unlike web apps, they are not run by a browser; instead, they are executed on a web container, which includes an API that grants access to device-specific functionality (Delía et al., 2017). This way, according to Delía et al. (2017), code can be reused for different platforms, all while still being able to distribute the app via the platform-specific app stores and being able to access native functionalities of the device. Thus, unlike web apps, hybrid apps can function offline and are “true applications” (Koram & Garg, 2023, p. 263). 

On the other hand, the web container may negatively impact the performance of the app, as it requires an extra load (Delía et al., 2017; Koram & Garg, 2023; Zou & Darus, 2024). Moreover, since it is developed using web technologies, the lack of native components in the user interface might have a negative effect on the user experience (Delía et al., 2017).

Examples of hybrid development frameworks include Apache Cordova (Delía et al., 2017) and Ionic (Zou & Darus, 2024). The latter also allows apps to be run directly in a web browser as a PWA in addition to distributing the app via native app stores (Pinto & Coutinho, 2018).

2.2.3 Interpreted Applications

Interpreted applications are often also built with JavaScript, but the majority of the project is translated to native code, with the remainder being interpreted at runtime, so that native interfaces are obtained (Delía et al., 2017). Due to the native components, a high performance can be achieved (Zou & Darus, 2024).

Some examples of frameworks that produce interpreted applications include Appcelerator Titanium and NativeScript, according to Delía et al. (2017). The researchers also state that Titanium’s API serves as a bridge, since it maps each JavaScript element to its matching native element, thus offering natively controlled user interfaces. Something similar is reported by Zou and Darus (2024): React Native allows developers to build performance-critical portions of the application in native languages due to its bridge which connects JavaScript with native modules. The fact that lots of components are directly translated to their native equivalents allows for responsive UIs and high performance; nevertheless, the JavaScript bridge may pose as a bottleneck at times (Zou & Darus, 2024).

2.2.4  Applications Generated by Cross-Compilation

Some applications can be directly compiled into native code, such as by using the Xamarin or Corona framework, so that an app version for each target platform is generated (Delía et al., 2017).

However, while in Corona, only one base code is written in Lua, a simple scripting language, Xamarin, on the other hand, only allows developers to write shared business logic code in C#, and each platform’s user interface still must be developed separately (Delía et al., 2017). But then again, Zou and Darus (2024) note that even though platform-specific user interfaces can be created using Xamarin.iOS and Xamarin.Android, developers can also choose to build a shared UI with Xamarin.Forms. Delía et al. (2017) might not have mentioned Xamarin.Forms because it was less widely adopted or fully developed at the time of their publication. Nevertheless, even though Xamarin.Forms allows developers to build a shared user interface, it often comes with trade-offs in terms of delivering a fully native user experience, as Zou and Darus (2024) emphasise.

Still, the approach of generating apps by cross-compilation often yields a performance close to that of native apps, and results in apps that look and behave similarly to as if they were written natively (Ebone et al., 2018; Zou & Darus, 2024). Furthermore, by compiling directly to native code, a framework like Flutter can get rid of issues associated with JavaScript bridges in other frameworks (Zou & Darus, 2024). However, Flutter requires developers to use a specialised language called Dart, which they must learn in order to build Flutter applications (Suri et al., 2023). 

2.3 Summary

To sum up, apps can be developed natively or by using the cross-platform approach. There are several types of cross-platform development which can be further categorised into web apps, hybrid apps, interpreted apps, and apps generated by cross-compilation. Each of these approaches differs, so depending on the specific requirements of an app, some might be better suited than others. Therefore, it is important to understand how these types of app development compare across different metrics, which will be elaborated on in the following chapter.

3 Comparison

When it comes to comparing different frameworks or types of app development, both the user’s perspective – such as the end user’s satisfaction with the app’s performance and user interface – and the developer’s perspective – such as the amount of support provided by the framework during development – can be considered (Karami et al., 2023). Out of all the studies assessed by Karami et al. (2023), almost half of them took both perspectives into account, while the other half was split relatively evenly between the two. Furthermore, the researchers highlighted that the criteria used to analyse the user’s perspective on an app’s performance and UI often included CPU usage, memory, battery level, launch time, and frames per second, while the criteria used to evaluate the developer’s perspective varied; examples included access to device sensors and the availability of framework documentation and support. On average, each study focussed on four criteria to compare different app development approaches.

The most used criterion for comparison is performance, as it was found by Karami et al. (2023) in more than half of the evaluated studies. According to Delía et al. (2017), this is because performance highly influences user experience, and a bad user experience will result in unhappy users, and thus bad user ratings. Furthermore, Karami et al. (2023) found the next most used criteria to be, in order: platform API accessibility, hardware and sensors accessibility and user interface, so the app’s interface’s quality from the user’s point of view. Thus, the main criteria include both some related to the user’s perspective, and some related to the developer’s perspective.

Additionally, Karami et al. (2023) categorised studies based on their evaluation methods: experiment-based studies assessed frameworks through prototype testing, while documentation-based studies analysed the frameworks’ documentation. The researchers found that two-thirds of the studies were experiment-based, providing insights into runtime performance but with results limited to specific prototypes – in contrast, document-based studies offered a broader API evaluation but lacked real-world performance insights. Few studies combined both methods or included user surveys, likely due to the time and effort required (Karami et al., 2023).

The following subchapters summarise findings by various researchers on how different app development approaches compare in specific metrics.

3.1 Performance

Karami et al. (2023) found that when it comes to performance, native frameworks always yield a better result than multi-platform frameworks. Furthermore, the researchers discovered that React Native was often perceived to affect performance negatively in comparison to other cross-platform frameworks.

On the other hand, Ebone et al. (2018) did not notice a relevant difference between native Android and iOS apps, a Xamarin Android app, and Appcelerator Titanium Android and iOS apps, while the Xamarin.Forms Android and iOS apps took significantly longer to load larger views. On top of that, the researchers detected that the UI response time patterns of the Apache Cordova apps on Android and iOS varied greatly on the platforms.

Similarly, Delía et al. (2017) also highlighted a difference between the Android and iOS platforms; they concluded that performance experiments involving the iOS and Android operating systems ought to be examined independently, as the native method in iOS is far more effective. The researchers believe that the native approach in Android might be slowed down because Java needs the Android Runtime (ART) to function. On the iOS platform, the native app also showed a significantly higher performance compared to the cross-compiled apps (Delía et al., 2017). Nevertheless, regardless of the operating system, a web development approach would be an easy way to get a high performance on all mobile devices, but only if the access to native functionalities of the device is not required (Delía et al., 2017). When analysing hybrid (Cordova) and interpreted apps (Titanium and NativeScript), Delía et al. (2017) realised that the type of JavaScript engine used in both approaches had a big influence on the apps’ performance: hybrid and interpreted apps running on Android, which uses the JavaScript V8 engine, had a much better performance than those running on iOS, which uses the JavaScriptCore engine. Hybrid and interpreted apps running on Android showed a similar performance to web apps and were thus even better than the native and cross-compiled apps, while the same apps running on iOS were worse than native, web and cross-compilation approaches (Delía et al., 2017). Thus, according to Delía et al. (2017), the apps which were cross compiled using Xamarin and Corona had the worst performance on the Android platform, but only the second worst on iOS. However, it is important to acknowledge that this study from 2017 may not fully reflect the performance of modern app development frameworks, thus highlighting the need for ongoing research in this field.

In a more recent paper, Koram and Garg (2023) stated that Flutter “is known for its high level of performance” (p. 264). Furthermore, the researchers found Ionic to have a moderate performance and React Native and Xamarin to have a performance “quite similar to native” (p. 265). Therefore, it would be interesting to analyse how different app development approaches compare in terms of performance today.

3.2 Memory, Battery, and CPU Usage

When it comes specifically to memory, native apps showed to use the least compared to Flutter and React Native apps, with the latter using the most (Karami et al., 2023). Furthermore, Karami et al. (2023) found React Native to also consume more CPU and battery than Flutter. Similarly, Suri et al. (2023) found React Native to have the highest memory and CPU usage compared to Kotlin and Flutter, but when it came to energy usage, both React Native and Flutter showed a very high usage. Given these findings, it would be valuable to examine how other frameworks than the ones mentioned compare in terms of memory, CPU, and battery consumption.

3.3 App Size

Compared to native Android and iOS apps, cross-platform apps are substantially larger (Ebone et al., 2018). Karami et al. (2023) point out that React Native apps are especially large. A similar finding was reported by Suri et al. (2023), who found that when comparing an app made with Kotlin, Flutter and React Native, the native Kotlin app used the least amount of space, while the React Native app used the most. This might also explain the before-mentioned high memory, battery and CPU usage by React Native.

3.4 Platform API and Hardware and Sensors Accessibility

Moving on, when it comes to the access to camera, geolocation, notifications, etc., most studies observed native frameworks to be better, especially since most multi-platform frameworks rely on third-party libraries to access some APIs (Karami et al., 2023). This finding is in line with the frameworks’ descriptions in Chapter 2.

3.5 Development Support

While relying on third-party libraries can sometimes pose limitations, it is also a significant advantage. According to Karami et al. (2023), popular frameworks like React, Ionic, and Flutter offer more third-party libraries and plugins and have greater development support. However, it is not clear whether this statement only applies in comparison to other cross-platform frameworks, or also in comparison to native app development methods. 

3.6 Code Smells and Bugs

Another metric of interest is the number of code smells and bugs. Karami et al. (2023) define a code smell as a “maintainability issue that makes your code confusing and difficult to maintain” (p. 136). When comparing native Android apps with React Native apps, the researchers noticed that native Android apps have more code smells. However, in large apps, native Android apps still tend to have less bugs than React Native apps. Based on these findings, it would be interesting to assess even more frameworks regarding their number of code smells and bugs.

3.7 User Interface

Lastly, when it comes to the user interface criterion, there is no clear winner on the cross-platform side; however, generally, most studies believe native frameworks to be more efficient in producing a high-quality interface than cross-platform ones (Karami et al., 2023). Which frameworks were evaluated in specific, though, is not clear.

Furthermore, Koram and Garg (2023) also believe native apps to be the preferred choice for delivering an intuitive user interface due to their high performance and reliability.

4 Conclusion

In the matter of app development, there are various approaches one can take. Choosing between them can be difficult, especially since each one of them has its advantages and disadvantages.

Patidar and Suman (2021) believe that developers should choose the native approach if they need the best user experience, the fastest speed, the possibility to fully make use of device features, and if they need the app to function even without an internet connection. Moreover, Karami et al. (2023) speculate that complex applications, such as banking apps, may need to be developed natively to ensure a better UI.

However, the native approach is expensive and takes a lot of time, so developers might choose to go for a cross-platform development approach. The easiest way to reach as many users as possible is to create a web app, as all that is required for distribution is a browser. Nevertheless, a web app is limited when it comes to accessing native device functionality. Another alternative is to develop a hybrid app, which according to Delía et al. (2015) still keeps the development effort small, similarly to the web approach. Furthermore, interpreted apps and cross-compiled apps are among the options as well, which are the most appropriate when the developer values good performance and user experience (Delía et al., 2015), but still wants to save time and money.

Whether or not a framework is a good choice might also look different from the perspective of a user compared to the one from a developer. For example, Karami et al. (2023) identified that Flutter is better from a performance standpoint, so it might improve user experience, while React Native is better in the case of development support. Thus, whether an approach or framework is the right choice depends on various factors, and it is up to the developer to decide which aspects to prioritise.

4.1 Limitations and Future Work

Due to the ever-evolving nature of technology, it must be considered that some of the papers cited in this work were published several years ago, and their findings may not fully align with the current state of technology anymore. For example, the tests in the study by Delía et al. (2017) were done on devices like the Samsung S6 and the iPhone 6 plus, both which were considered high-end at the time, but would not anymore in 2025. This highlights the need for new studies to validate, refine, or challenge these earlier findings. Conducting research with the frameworks and devices available today can provide updated insights and ensure that our understanding keeps up with current developments.

REFERENCES

Delía, L., Galdamez, N., Thomas, P., Corbalan, L., & Pesado, P. (2015). Multi-platform mobile application development analysis. 2015 IEEE 9th International Conference on Research Challenges in Information Science (RCIS), 181–186. https://doi.org/10.1109/RCIS.2015.7128878

Delía, L., Galdamez, N., Corbalan, L., Pesado, P., & Thomas, P. (2017). Approaches to mobile application development: Comparative performance analysis. 2017 Computing Conference, 652–659. https://doi.org/10.1109/SAI.2017.8252165

Ebone, A., Tan, Y., & Jia, X. (2018). A Performance Evaluation of Cross-Platform Mobile Application Development Approaches. 2018 IEEE/ACM 5th International Conference on Mobile Software Engineering and Systems (MOBILESoft), 92–93. https://ieeexplore.ieee.org/document/8543442

Karami, P., Darif, I., Politowski, C., El Boussaidi, G., Kpodjedo, S., & Benzarti, I. (2023). On the Impact of Development Frameworks on Mobile Apps. 2023 30th Asia-Pacific Software Engineering Conference (APSEC), 131–140. https://doi.org/10.1109/APSEC60848.2023.00023

Koram, N., & Garg, R. (2023). Review on Mobile App Development: Tools and Techniques. 2023 IEEE World Conference on Applied Intelligence and Computing (AIC), 260–266. https://doi.org/10.1109/AIC57670.2023.10263908

LePage, P., & Richard, S. (2024, September 19). What makes a good Progressive Web App? web.dev. https://web.dev/articles/pwa-checklist

Patidar, A., & Suman, U. (2021). Towards Analyzing Mobile App Characteristics for Mobile Software Development. 2021 8th International Conference on Computing for Sustainable Global Development (INDIACom), 786–790. https://ieeexplore.ieee.org/document/9441097

Pinto, C. M., & Coutinho, C. (2018). From Native to Cross-platform Hybrid Development. 2018 International Conference on Intelligent Systems (IS), 669–676. https://doi.org/10.1109/IS.2018.8710545

Suri, B., Taneja, S., Bhanot, I., Sharma, H., & Raj, A. (2023). Cross-Platform Empirical Analysis of Mobile Application Development frameworks: Kotlin, React Native and Flutter. ICIMMI ’22: Proceedings of the 4th International Conference on Information Management & Machine Intelligence, 1–6. https://doi.org/10.1145/3590837.3590897

Zou, D., & Darus, M. Y. (2024). A Comparative Analysis of Cross-Platform Mobile Development Frameworks. 2024 IEEE 6th Symposium on Computers & Informatics (ISCI), 84–90. https://doi.org/10.1109/ISCI62787.2024.10667693

The post SOTA | Comparing App Development Approaches: Native vs. Cross-Platform App Development appeared first on Mobile USTP MKL.

Das Hauptziel des Forschungsprojekts “Smart Communities – IoT4LAC” besteht darin, den Datenaustausch zwischen verschiedenen regionalen LPWAN-Serviceanbietern zu ermöglichen und den Nutzer*innen durch aussagekräftige visuelle Darstellungs- und Interaktionsmethoden einen tieferen Einblick in die komplexen Daten von Sensornetzwerken zu bieten. Es wird ein System-of-Systems-Konzept entwickelt, das verschiedene Anbieter und Anwendungsfälle integriert und als Grundlage für die Realisierung von Smart Services für Gemeinden, Verbände und das Land dient.

Zielsetzung

Im Rahmen meiner Mitarbeit im Projekt bestand die Aufgabe darin, eine Visualisierung als Grafana-Plugin zu entwickeln. Dieses Plugin sollte es ermöglichen, zwei Attribute in Kombination miteinander über einen definierten Zeitraum darzustellen, sodass die Nutzer*innen einen Überblick über historische Daten erhalten. Darüber hinaus sollten Usability-Tests durchgeführt und umfassend evaluiert werden, um die Benutzerfreundlichkeit des gesamten Dashboards, das im Forschungsprojekt erstelltet wurde, zu bewerten.

Vorgehensweise

Zunächst wurde das Plugin unter Verwendung von Javascript und D3.js umgesetzt und in das Dashboard integriert. D3.js wurde dabei genutzt, um interaktive und dynamische Visualisierungen zu erstellen. Anschließend mussten verschiedene Interaktionsmöglichkeiten implementiert und mit den bestehenden Plugins verknüpft werden. Nach der technischen Umsetzung wurde ein Testdesign entwickelt und potenzielle Testpersonen kontaktiert. Für die Usability-Tests wurde ein Fragebogen mit sechs spezifischen Aufgaben sowie einem Visualisierungs-Literacy-Test erstellt. Die Testpersonen haben diesen im Rahmen der Evaluierung ausgefüllt. Schließlich wurden die Ergebnisse der Tests analysiert und ausgewertet.

Ergebnisse

Im Rahmen meiner Mitarbeit lieferte ich eine detaillierte Beschreibung des entwickelten Plugins und seiner Interaktionen sowie eine umfassende Auswertung der Usability-Tests. Diese beinhaltete eine Beschreibung der Methodik, die Durchführung der Tests sowie die wichtigsten Erkenntnisse aus panel-spezifischem und panel-übergreifendem Feedback. Der berechnete SUS-Score von 60,625 liegt dabei unter dem Durchschnitt, was auf Verbesserungspotenzial hinsichtlich der Usability hinweist.

Retrospektive

Durch meine Mitarbeit im Forschungsprojekt “Smart Communities” konnte ich meine Fähigkeiten in den Bereichen Programmierung und Evaluierung weiterentwickeln. Besonders wertvoll war die Möglichkeit, eine Kombination aus technischen und benutzerzentrierten Aufgaben zu bearbeiten. Die Umsetzung des Plugins sowie meine Beteiligung an der Entwicklung anderer Plugins ermöglichten mir, umfassende Usability-Tests durchzuführen und die Ergebnisse mit meiner vorherigen Arbeit zu verknüpfen. Dies gab mir wichtige Einblicke in die Benutzerfreundlichkeit und die Verbesserungspotenziale von interaktiven Visualisierungen in Dashboards.

The post TFG | Smart Communities – IoT4LAC appeared first on Mobile USTP MKL.

Screenshots des Küken Chatbots: Landing Page

Was ist der KÜKEN Chatbot?

Der Chatbot dient als zentrale Kommunikationsschnittstelle des Projekts und steht bereit, um Fragen zur Mülltrennung, Infos zum Projekt, Fragen zur Organisation und weiterem zu beantworten. Der Chatbot nutzt vorgefertigte Dialoge, die in Flussdiagrammen visuell entworfen und mit Natural Language Processing (NLP) trainiert und verknüpft wurden. So ist es möglich präzise Antworten zum Thema Abfallwirtschaft zu erhalten, ohne dass der Chatbot in andere Themen abschweift.

Screenshots des Küken Chatbots: Start der Konversation

Technische Umsetzung

Für die technische Umsetzung des Chatbots wurde im Backend mit Node.js gearbeitet und im Frontend mit Vue.js und Vuetify. Die Dialoge des Chatbots wurden mit Fabble.io geschrieben (Fabble.io ist seit dem nicht mehr in Betrieb) und anschließend exportiert und mit NLP trainiert.

Wie funktioniert es?

Der Chatbot wird im nächsten Testlauf des Forschungsprojektes “KüKeN” durch scannen eines QR-Code am Kübel mit dem Handy erreichbar sein. Es gibt zwei Optionen zur Interaktion mit dem Chatbot:

• “Bubbles” auswählen: Wähle vordefinierte Begriffe am unteren Bildschirmrand aus.
• Freie Texteingabe: Stelle spezifische Fragen direkt an den Chatbot.

Unser Ziel ist es, interessierten und motivierten Personen schnell und präzise die nötigen Informationen rund um das KüKeN-Projekt zur Verfügung zu stellen.

Screenshots des Küken Chatbots: Freitexteingabe

Retrospektive

Dieses Projekt war eine wertvolle Lernerfahrung für mich. Besonders faszinierend war es, mehr über die Gestaltung von Dialogen und die Funktionsweise von Chatbots zu lernen. Die Herausforderung, präzise und nutzerfreundliche Interaktionen zu entwickeln, hat mir neue Einblicke in die Verbindung von Technologie und Kommunikation gegeben.

Link zur KüKeN Projektseite

The post KÜKEN Chatbot: Der sprechende Mistkübel! appeared first on Mobile USTP MKL.