Was a greenfield prototype of mobile application for STU (Slovak University of Technology) and its students. The project was stopped because of unrelated reasons, right after the development of the MVP.
I wore many hats - as I was the main developer, and "architect", and if you want, also a designer and product owner. I started the development with market research, then I developed backend and finally mobile app.
STU (university in Slovakia, Europe) had no mobile application for its students and the use of mobile-unoptimized web app called AIS was a real pain. AIS had no APIs documentation, no public APIs available so everything needed to be analyzed and developed from scratch. Because the university is called Slovak Technical University (STU), I decided to give it a name Mobile STU-dent.
I create apps for the users, not myself. This was the main reason why I created questionnaire as a part of market research. Then with small help from people working at the university, I distributed it to almost 1200 students aged 18-25, as they were intended to be the future users of the app. Most of them were undergraduates in the process and most of them being men as it was IT faculty, who gave the most responses (that faculty was FEI, Faculty of Electrical Engineering and its students gave almost 70% of all responses.). You can see the examples below.
Market. Next questions were aimed to find, if there was any potentional to build successful app. The answers (see the pic below) just confirmed, that such a mobile app, would be a real "market success".
Next few questions were about the devices that I should support. It seemed that 1 iPhone user corresponded to 3 Android users.
However, I made also mistake in one question (everyone makes mistakes) - the question on the right.
Another 2 questions were about the necessity of having something like background processing logic in the app. Something like what Facebook is already doing - prefetching fresh content, so if the user opens app, he will not see "Loading" screen as the data are already downloaded. I was also interested in if the background logic should be implemented only, e.g. when users are on wifi:
Later in the project I got a recommendation from my friend, that we should try crowdsourcing to fund the app development (the pic below). As most people (almost 68%) gave answer that they would not support such movement because "It is responsibility of the university", I did not think the crowdsourcing would be successful in this case.
Because in 2020 mobile app are heavily animated, agencies could charge half a million of dollars for custom-designed, highly animated app. But in the market without no real competitors, people were desperate more about functionality than the design (see the pic below). On the scale from 1 up to 5, 5 meant having a lot of functionality and 1 meant having the-best-ever design.
And finally, the last, but the most important question was about the desired features. People got very creative with last question and offered very precious advices, wants and "dont's" (in Slovak language, so I do not share the pic).
96% of responders wanted to display the content from the AIS, public faculty websites, and see information about their accommodation. They also wanted to see what will be for the lunch in the restaurants nearby, built-in events-reminder, in-app messaging, notifications about cancelled class, and many more. To get information, students used multiple channels - e.g. either mail, internal noticeboard but also Facebook, public websites (that are mostly in each faculty domain), or even using private resources like Slack.
It is really, really important to know about deeper context of the user environment. It is not just building the app itself - you are solving problem by building the app. And to solve problems efficiently, you need to know the real character of problem. E.g. if you wanted to build an app, that would be used in the factory with different kind of people, there would be likely very different outcomes of the initial research.
The questionnaire summary a.k.a UX / UI persona
To generalize users, UX people usually decide to create a few imaginary people that represent some major parts of the end users - and they call them personas. I will call my persona John.
"the" John persona
is 20 years old, he studies informatics and he logs into AIS on daily basis, using wifi or cellular connection (it seems that the connection type does not really matter, as he expects that he will not download a lot of data). He is more interested in the features and functionality of the app instead of having top-class, highly-animated, wonderful design. He wants to use the app to see content from AIS, browse fresh content from faculty websites and display information about accommodation services.
I prefer making data-based decision. As you can see, it is important to know your users, what they want, desire and where you should not put much focus. You are building the app for the users, not for yourself. If the users are not available, there is possibility of going with Analytics ( develop very thin MVP asap and track behaviour's of the first users and adapt app rapidly).
Reading between the lines - if the app should be developed for commercial client, it would probably pay off to include the ads because most people logged in on daily basis. However, I finally decided not to go that way - (academical environment).
Because I was limited by time (cca 4 months) and it did not looked very real to develop all the features that users wanted, I decided to prioritize requirements - something what stakeholders would do too. If I would develop successful MVP, then it seemed more realistic for me to on-board more developers (or students) to implement next features (that's what I thought).
So, I decided to develop only these features for the MVP:
- Displaying news from the faculty (organization-like) public websites
- Displaying news from the auth-walled AIS
- Mails integration - downloading & replies
- Browsing schedule, completed subjects, grades, syllabus previewer
- Downloading personal profile details
Architecture Background - Legacy Everywhere
Now, if we know about the real-world app context and have the real analysis of the user base, we can start thinking about implementation. It is really important to analyze the user base, THEN define one or multiple personas / specifications / requirements / use design-thinking / call-it-like-you-want and only THEN start thinking about implementation or architecture. This is not obvious even for some enterprises. Put requirements first. "Without the goal, you can not score." - is not just a motivational motto.
Each student at STU gets access to 2 mailboxes - one is AIS internal only (and supports POP3 only), and the second one can be used for receiving emails from public using IMAP (hosted and probably managed at organization level).
In the time of writing this, there is also Google Suite available - but I did not investigate if (and how) it could be used.
AIS (Academical Information System) is central system (written in Perl) with no public APIS used by students and people at the university. It supports payments via gateway, generates schedule, and pulls and submits the data to the governmental organizations (think a master thesis is submitted into national-wide anti-plagiarism system). The AIS has many other features that are not really important. However, the AIS was the main source of the data for the mobile app and it used authentication (you needed to login to see your data like emails, etc.)
The interesting thing was that almost all services shared same instance of LDAP, so students could access different applications by using the same credentials. I was playing with the idea to use it for building authentication service - but unfortunately, LDAP was placed in private network / without public access.
Public (un-authenticated) services
I have also discovered one service, that pulls data out of AIS, but it is doing it without any security. The only advantage was, that it offered API-like functionality - I did not have to write much code for getting information where the person is working.
Software Components Overview
I created this diagram because, it is better to see how the overall environment looked like, than just to read about it:
All without docs, or any APIs.
No presence of APIs or docs forced me to analyze network traffic mostly with Postman. Writing backend as single-point of integration of various data-source took me a few weeks - but let's now focus on the mobile app, as this would be probably the idea why you are still reading this.
Mobile STU-dent - Mobile App
To be honest, the original design was, like, not very pretty or eye-catching. But because many people helped me in one or another ways and I even asked the person for feedback of that bad-looking app, I did not want to leave it without any additional work, redesign or so called "final-touch". It is also important to say, that the app had same functionality as after re-design.Let's start with so called onboarding.
Because I was building app on the top of legacy system where students already had their accounts created and I did not want to include any functionality that needed private backend-storage in that time, I decided to create only very "dummy" onboarding. I try to question everything and I, simply, missed the point of any "registration process". Users already had accounts created, and if they forgot the password, they needed to restore it by presenting their ISIC (student ID) card physically at one of the faculty's offices.
The only very-early idea of registration process was to gather user's consents in terms of GDPR. I was planning for that, but decided to put this feature on the bottom of the backlog, and develop the feature later.
So, let's take a look at the simple onboarding process:
I also planned to add support for biometric login (fingerprints or face-scan), but I did not get into implementation of that as there were many features with higher priority. However, when I am thinking now about it, putting this on the bottom of the backlog was a mistake, as having the possibility of very simple login, just by using fingerprints of FaceID, would be very beneficial for the end-users.
The idea was to put on the main screen information, that were / are relevant to the time when user would open the app.
Having something like "Upcoming Events" section greatly opens path to the extending original requirements.There could be added many additional features like: "events-reminder (calendar integration), in-app messaging, notifications about cancelled class" - all what users wanted.
The students were interested also in displaying the number of the week in the semester and very often forgot password to the wifi at the campuses.
In these screens, I tried to merge 3 different kinds of the news sources (one was behind authentication, another one was totally unsecured / public and the last source of the news was used to provide archived news). Moreover, from the technical point of view, only one source was able to provide something like a secondary title for the item, that's the reason the news in top horizontal scroll area have different design.
What could be improved here ? I guess, that I could merge archived news into single news feed. Again, because of the tight deadline and as this would require backend storage, I decided not to go with it for MVP.
Browsing and writing mails
This was actually the hardest thing to implement because of the limitations of the mail servers that were used in production. One mail server, could be accessed only by POP3 protocol, while another one (managed by university itself) supported IMAP.
I do not want go into lot of details, as it is not the purpose of this post, but the performance comparison was huge. With IMAP, I could download the mails almost just-in-time, but with POP3, it took me from 13 seconds up to 70 seconds. I did not have access to the POP3 mail server's administration, so I did not try to tune it up.
Because of performance differences, the first idea I got was to separate the mailboxes (separate the mailbox streams in UI), set the faster mailbox to be viewed as first by default, and also start fetching data from the second mailbox (the one that was x-times slower) in the background as soon as possible, right after application startup. See the first iteration - or how I separated the mailboxes.
If you take a look at the design of the mails screen above and think about it, you would probably see the first screen being redundant, unnecessary. To see the mails, you would need to click on some "abstract" folder. The point is similar as in the home screen - you should optimize app to the time and user context to save the user clicks or taps for actions that are executed most often. There are different techniques to achieve this: like autofocusing inputs, selecting actual location in apps that use location, or grouping logic that is not often accessed behind buttons with title "Other".
My motto here was: "Keep it simple & Do not make user think."
You, me, and the students are interested in the mails, not in the mail folders.That's why I decided to make something like this (most-left pic):
It is also important that this is based on the assumption, that most emails are sent to the external, not internal mailbox. But as every assumption, this one also needs to be tested later by using analytics with real users or we would need to add this into "user settings".
And to be honest, another thing that I made probably wrong, was that I tried to implement merging mails in the device - now I think this kind of logic should be moved to the server & tune up slow mail-server, just to keep the mobile client more "dummy". Well, everybody makes mistakes.
This also belonged to the harder parts of the project - because of the process of data were retrieved. But, this was the result. Another idea, which could be implemented easily, is to browse already completed subjects - but I wanted to keep MVP as thin as it was possible.
Personally, this was probably the easiest part of the whole project. The screens were made upon assumption that most people at university communicate with more less the same people over time. This fact resulted in things like saving search history on the device, and the creation of "Favourite people" area, where you could add people in something like "top contacts".
If you read everything to this line, maybe you have question - where was server-less used ? Well, this was my first project that I managed completely on my own (research, planning, development, devops) - and it was totally different than full-time job, so I published it here for you to see, how I work.