Application Critique

So this week’s blog will be on critiquing on Group 2’s presentation of Snap & Eat application by the Health Promotion Board

Summary

I will summarise the presentation into 3 points:Unwelcoming Onboarding, Broken Features and Poor UX.

Unwelcoming Onboarding

For any application, the initial onboarding and first impression makes the biggest difference on users. A good onboarding process would smooth the user into using the application regularly and also to allow the user to make the best use of the application. In the Snap & Eat app though, users upon registering were consistently bombarded with terms, conditions and requests for permission. This sort of makes the app feel hostile or unfriendly towards the new user, rather than getting the user into the flow of things first and then requesting the permission only when the user wants to perform a related action. Since the user was the one who wants to perform the action, he/she would be more than willing to grant the app the permission at that point of time. With regards to the terms and conditions page, how this was overcome in OneService, another government app, was that the user was asked to agree to it at the bottom of the registration page and only shown the full terms upon request. This makes the process less hostile towards a new user and does not overwhelm the user with agreements and permissions. Thus the reason why it was this way, is probably due to the developers not thinking of the user first, but simply to clear their own requirements first without much concern for the user.

Broken Features

The presence of broken features in the app such as the food recognition function, and also including a blurb that provides a random description of the product. This seems to be indicative of how the requests of the client, seem to overrule any sense of User Experience. That developers were simply including features for the sake of the client’s request, without arguing for the user experience of how the features they want do not work or simply do not value add to the application. This, in turn, decreases the overall production value of the application, as it feels like it is not user-centric and lacks the polish of a proper app but is instead just a crude dumping ground of features from a client.

Poor UX

In general, the application does not seem to have much thoughtfulness for the user. Things like having to swipe the navigation bar, which is not typically intuitive to users, including large amounts of text and pushing away the key information, requesting for large amounts of information from the user even when they are not needed, or a poor choice of controls for the user that is not intuitive or convenient for the user. In general, it felt like the application was created to simply check off a checklist of required features and components, rather than a cohesive package that value-adds to a user’s experience.

Original Thoughts

With regards to Snap & Eat, while not having used the application directly, I’ve used Healthy 365 (the app for the National Steps Challenge) that is another application by the Health Promotion Board. The Healthy 365 app and Snap & Eat apps seem to be almost carbon copies of one another, with a simple reskinning of the colour of the UI and yet having almost exactly the same navigation bar, icons and additional features like the food journal.

Having had several bad experiences with the Healthy 365 app, a synchronous UI for example, whereby every action you perform prompts a “loading” symbol that freezes the entire UI. I’ve even been locked out of my account, whereby I changed my phone then attempted to restore my account, but everytime I press restore the application simply crashes. There are many fatal UI flaws within the app, and yet people use it solely due to the amount of financial benefit for the users by participating in these HPB challenges and rewards. If an actual cohesive experience was presented by HPB, the app could have much more far reaching benefits especially with such a large captive userbase.

While I’ve yet to use HPB’s new HealthHub app, which visually looks way better than their previous apps. HPB would greatly benefit from having a single well-done application that covers all their initiatives and challenges, while also providing the extra features like a food journal. Creating an app for every different challenge, and then carbon copying many of the features simply isn’t sustainable and leaves many of their users high and dry after the challenge. But having a single sustainable app, that constantly updates with new challenges and new initiatives would definitely keep users engaged to the application. While there are many health applications out there, none of them have the potential to be as customised for local needs as one that is thoughtfully developed locally.

For this to happen, HPB needs to engage a proper developer that cares such as GovTech, rather than choosing the lowest bidder for their project. Having worked at GovTech on their OneService application, I’ve seen how the team and project managers often fight back on decisions from the client side on user experience basis. Such as removing a legacy UI component that confuses the user, or by redesigning certain screens to make them more user friendly. Many of these initiatives were brought up from the team’s side rather than the client to create a more thoughtful experience for the user. When I first started my internship, the old OneService UI was horrible and clunky, however the UI components that I’ve worked on and the UI refresh is a step on the right path to make an overall better application. I think this also signifies a new direction for the development of government apps, to create an app for the people and not an app for the ministry. I think if the government wants to succeed in truly creating a smart nation, we have to start from there.

 

Presentations + UI Design

So here’s my blog/reflection for Week 3 of CS3216’s Lectures~

General Impressions

This week, we had two rather different lectures one about Presentation and one about UI Design, though they are somewhat similar in that they are about getting information across to another party. For the Presentation lecture, I think that Prof Damith brought up rather good points on how best to structure things and what to go for. I roughly knew many of his points, I’ve just never been able to formulate it into a clear cut structure that could be easily taught to others. For Su Yuen’s lecture on UI Design, I think she helped to nail down the key elements of UI Design and what to look out for to streamline a design. For a UI to be intuitive, it is not just what is intuitive to you but to an average user without guidance. I think to distil it into such a clear test is really pretty interesting.

Key Ideas

Damith’s lecture helped to more clearly structure your presentation, from starting with a PUNCH, to forming a storyline for your presentation, supporting your presentation with evidence and then ending with a big idea. It is definitely quite a streamlined form, and easy to remember. Though I feel like by default, many presentations are already structured that way or are intentioned to be structured that way but get lost along the way. He also taught ways to make a stronger impression on people, by focusing on your intention behind the presentation, making it clear why the audience should care and having a call to action.

Su Yuen’s lecture was rather useful in that she defined very clear and simple tools that we could easily and effectively apply to our any UI. To list down the 3 main actions on a page, rank them and design accordingly is a really simple and easy way of doing things. Testing through like getting a person to fiddle through an interface and “think out loud” also definitely helps us better understand what a layman would do. As sometimes we forget how tech-inclined we are, and how some that was intuitive or standard to us may not actually apply to other people. Lastly was also how to empower non-UI designers through the use of templates, while also having slight modifications to suit the required needs. She made a point about how we like to build things from scratch that we tend to forget that there are simpler ways to achieve things i.e. through templates.

Agree/Not Agree

The point Su Yuen made about how we like to build things from scratch and not use libraries, I think I saw a great deal of that in my internship. Where the senior developer would rather build an entire component himself, than rely on an open-sourced library that already has the features nailed. Definitely there are merits to building things yourself, such as having stronger control over your code. But I feel in the greater scale of things, the time saved from building the item from scratch and maintaining the additional code base is definitely a lot more worth it, if eventually you’re arriving at the same product.

I definitely agree with the tools that Su Yuen introduced as well, and the way she streamlined how we should determine what should or should not be on a page when we designed it. I think I posted many of my agreements and reasons above already.

With regards to Damith’s lecture, I definitely believe less is more in terms of slides. My slides have always typically been single focus slides, so each slide is simple with maybe one point and instead that are multiple slides that would better illustrate the various points rather than cramming all the points into a single slide.

In the end though, I also think that slides can only help a person so much and no matter how far you try to follow a template. There is always an unreachable glass ceiling that is intuition and charisma. Regardless of the slide deck, if you are a charismatic person, people will listen and be enthralled by what you are saying. If you have the right intuition you will know at a glance how to organise a slide (although I guess this could be aided by his tools).

Questions I Have

Well, I don’t really have any in particular. I guess additional tips on UI design would be great, like maybe more on colour matching as well as providing focuses

-Jeremy

Software Engineering + SCRUM

So here’s my blog/reflection for Week 2 of CS3216’s Lectures~

General Impressions

Well first up, here we are again back to learning about “Software Engineering Principles” in school again. I feel like the reason that most of us did not remember learning about AGILE in CS2103 (even though they taught it) was the fact that we just do not need to apply it in school, and thus becomes just another “fluff” model that disappears from our memories. Thus to learn about Software Engineering processes again, while good in theory would tend not to stick in people’s heads generally because they are unable to see the need nor importance for it. The difference then comes in whether you’ve actually experienced or practised these Software Engineering principles during an internship, and you only get to see the importance after going through it. As someone who went through SCRUM for 3 months during my internship, I got to experience and jump straight into the deep-end without having much of a prior understanding of what SCRUM was (cause I like other 2103 students just threw that knowledge away). To be back at learning software engineering principles again after going through it, I feel like it is something you can never learn in class but something you must experience in practise to ever understand or remember.

Key Ideas

Software Engineering is not just about programming, but rather in my opinion is to create a system that is sustainable and be able to craft out a product that is easy to maintain as well as enhance. This includes, as the lecture mentions, processes, programming and people.  Processes to set the right processes in place so you don’t end up with a Big Bang situation for example. Programming to create code that is extensible rather than monolithic structures that cannot be changed. People to have the right mix of people to be willing to commit to sustainability.

Other things, tl;dr. Waterfall bad, AGILE good. Well it’s not a blanket rule I guess, and I will elaborate more on it later on. But generally most of the lesson was on how to create sustainable systems, decomposing the system into sub-components creating components that are high cohesion and low coupling and the correct way to structure your tasks in order to get work done such as prioritisation. Also testing, testing, testing and documentation (the things every CS student typically hates in a project).

We also went through how SCRUM really works. (Which is about the same as what I had the fortune to practise during my internship)

Agree/Not Agree

Waterfall Bad, AGILE Good – Agree mostly for large complex projects. Disagree for small projects. Small projects can have the tendency to over-engineer if you implement AGILE on it, while it’s definitely a case to case basis (duh).

SCRUM (generally) – I think that SCRUM is a great procedure to make software development for flexible and adaptable, however I think that it is also important for people not to adhere to SCRUM religiously. By this I mean that SCRUM really works when you are flexible and it provides you a useful way to keep your team in touch while also easily prioritising tasks. However, I’ve also heard of cases whereby a SCRUM Master follows SCRUM so religiously that he does not allow any task to be added to a Sprint once a Sprint has started. While this definitely prevents extra work for the team, there are downsides in that the task he blocked was a severe bug in the application and he insisted on leaving that for the next Sprint even though the bug was crippling productivity. (Sounds ridiculous and without common sense, but it actually really happens)

SCRUM Time Estimations – Well, we all know that Time Estimations never go well. Even if we defensively say that we may take 1 day to do a feature that we may typically do in 2 hours. When we encounter certain bugs, it can take us days to solve something we thought was pretty straightforward. And when you encounter these bugs, you start to think that exceeding the time estimation is fine as it is a special case. Then slowly you start to let exceeding the time estimation to become the norm, and eventually you give up doing time estimations all together.

EPICs + Tickets + Sprints – The combination of Epics and tickets under Epics (in the JIRA system) with the use of a Sprint system can really increase the efficiency of a team. As it makes the tasks ahead that a team needs to do really clear, and thus it allows people a better gauge of how efficient they need to be with their work and how much time they need to rush.

SCRUM Processes – While SCRUM is great and all, there comes with it quite abit of downsides (that wasn’t talked about today). While I practised SCRUM we had biweekly sprints, whereby at the end we would do a Sprint Review and a Retro. These things typically took up an entire day, and 1 day out of 10 is almost 10% of the productivity gone due to meetings.

Questions I Have

I don’t really have any particular question directed to today’s materials, partially cause we’ve seen it all before and it is mostly just a factual retelling. However one thing that I am curious about is whether there are any new up and coming Software Engineering Processes/Principles? That may potentially overthrow or be a better alternative to SCRUM/AGILE?

Yeap that’s it!
– Jeremy

What you hope to learn in CS3216

Within CS3216 I hope to learn, on the technical side, more about backend system and how to operate them as till now I’ve mostly only worked with local or front-end systems, with backend experience being consuming APIs or working with Firebase. I believe that CS3216 will give me valuable experience on working on the back-end and setting up servers, and hopefully a better understanding of how it all works together.

On the non-technical side, I feel that CS3216 will give more exposure on how to analyse existing projects and try to initiate and conceptualise new ideas. In terms of pressure, I think CS3216 will also give me the experience of working on a project and having to pivot multiple times in order to arrive at the right one. Working with multiple teams will also be an interesting scenario as I have yet to experience working with people of different majors for a technical project, but my experience of group projects in USP has led me to believe in the strength of having a diverse team across all majors. I hope that this blend of diversity can culminate in the production of awesome and unexpected ideas that could only have arrived from this multidisciplinary approach.

All in all, while CS3216 will give me exposure on the technical side, I believe that the non-technical side is where I stand to get the most growth 🙂

First blog post

This is your very first post. Click the Edit link to modify or delete it, or start a new post. If you like, use this post to tell readers why you started this blog and what you plan to do with it.