DEV Community: Cinnamon Agency

Apple Music’s User Experience Problem

Cinnamon Agency — Thu, 04 Aug 2022 10:57:40 +0000

Let's have a look at Apple's UX issues after they replaced iTunes with a new premium subscription-based streaming service called Apple Music.

Why Apple Music?

As a convert to the Apple Club, I’ve spent the last 10 years using Apple products and appreciating the philosophy of good design Jobs ushered in way back when.

Over those years I got hooked into Apple’s ecosystem because for me “It just worked.”

One such adoption was iTunes. Spending my fair share of time carefully curating my music library and faithfully syncing it to my trusty iPod.

In the meantime I discovered Spotify and the years passed by while my tried and true iTunes library began to collect digital dust.

And after much speculation and rumor, Apple finally jumped into the streaming race — retiring iTunes altogether, replacing it with their new app called Music with the optional feature of a paid subscription-based streaming service named Apple Music.

Many Spotify years later, I decided to give Apple’s take a good fighting chance. I ended up using Apple Music for just about a year.

So without further ado, here are some of my collected thoughts as a Product Designer and just as a normal person who wants to listen to music, on what Apple Music gets wrong.

Search

One, if not the, key ability in a music app is search. It's easily in the top three things you do in an app like this. So why does Apple find it ok to keep search in the dark ages on the desktop? Let's take a look at what I'm talking about...

Let's say we want to search for a fairly well-known rock band. Let's go with Weezer. They’re a cool band.

Ok! We've successfully typed Weezer. It seems this auto-suggest has appeared. But wait — is it an auto-suggest?

Let's try and type "Wezer" and pretend we misspelled the band's name to double check that this indeed is an auto-suggest helping us confirm it matched us to Weezer in Apple's library.

Great. So I guess this isn't an auto-suggestion. But then, do auto-suggestions exist in the app at all? Let's find out... How about we pick a really popular rock band — Queen.

Wait, what? Why does Queen get a nice quick-access result and Weezer doesn’t? ;(

Oh well, let's carry on to find out where our search leads. Let's click on that dropdown and commit to where it will take us.

Ok! So, it looks like we are on a brand new "results page". Fair enough. It would have been nice to be able to skip this page entirely (like when we searched for Queen) as all I really wanted to do was go directly to the music of Weezer. But ok.

Let's go back a page and think about what we'd like to do next. Now — I don't remember where I was last, but I do know I'd like to get back there. So how would we do that? Probably with a back button like in our internet browser, right?

Well, no.

So as it turns out, there is no back button. At least, there is no universal back button that will undo any navigational action you’ve taken. Can you guess why maybe?

Navigation

I don't know about you — but I find Apple Music's navigation to be one of its most confusing aspects. Great applications don't make you think about where you are, you just know; great apps make it easy to undo and go back to where you were. Really great apps don’t make you think, “Oh great, I'm lost, how do I go back.”

Apple's Human Interface Guidelines for iOS offers three types of navigation for applications, and it seems Apple has used these concepts in macOS too. Because as it turns out, Music uses Flat Navigation.

Cool — we have a sidebar, so that makes sense right? Kinda? I’ll tell you why I think it doesn’t make a lot of sense. Flat navigation works great in mobile experiences because screen real estate is small, you frequent the navigation bar a lot, and you can tell which tab you’re on. You can also expect to more deeply explore one tab independently of another.

This is a convention that’s stayed since the iPhone launched and for a good reason — it functions well and people don't easily get confused about where they are. So how does this work on the desktop?

In short this also means each item in the sidebar has its own independent navigation. Now let's take a look at how Spotify handles navigation on the desktop.

Notice anything? Spotify seems to combine the benefits of an always-accessible sidebar but allows you to easily retrace your steps no matter where you clicked in the app. In other words, they include a back button whenever you navigate.

Why is this in my opinion a better approach than Apple's?

It reduces cognitive load. People don't have the time or willpower to have to remember where they last navigated in a music app.

It leverages existing conventions. People are used to using their internet browser's back button. Spotify utilized this so the behavior for new users is as expected.

It brings down the anxiety levels and allows users to explore freely without the fear of messing up and not being able to fix things.

System Feedback & Exploration

Clicking is a big part of any app, because, well, you need to click to navigate anywhere. But here's where things again get a little hairy with Apple Music.

Take the humble and unsuspecting now-playing bar.

Ever since the inception of iTunes, this has largely remained functionally the same — a way to see what song is currently playing.

So we're rocking out to one of Weezer's new songs and we think, "Hm, this band is great, let me check out the rest of their catalog!" Let's click on Weezer from here!

Oh wait, what. We clicked on the title and the album. Nothing worked ;(

Can you guess how we would navigate to any of these links?

Clicking on the “More” menu, scanning through a list of items before seeing the item “Show in Apple Music” at the bottom of the list.

But what about in other areas of the app — can you click on songs, albums, or artists there?

Turns out that is also a no-go.

At this point you might be wondering, why am I making an issue over this? Because I think the entire point of a music app, especially one that's about finding new music in an immense streaming library, is to click around, explore, and to easily find songs, albums, and artists. I don't think the user should be punished for not adhering to how the app wants you to use it.

And if it's about consistency, (Apple sticking to their guidelines) consistency for consistency's sake isn't always the answer.

Response Time

A good app doesn't make you wait. We know load times drastically impact drop-off rates on the web, I don't think we have to treat native applications differently.

And this leads me to one of biggest pains in using Apple Music:

Waiting and waiting between pages. Wondering what the next funky behavior will be. Losing my scroll position. Not knowing if my song will actually play when I click "Play". Confusion as to why Music can't take me back to the exact moment where I left off when I quit the app. The list, unfortunately, goes on.

Wrapping Up & Real Talk
So is Apple Music really that bad? I believe good design should be desirable. I want to like Apple Music. And more so because I believe Apple still has strong design principles. But I can't. The product has simply not allowed me to enjoy its experience. I have to fight it in order to use it.

Which is a shame because there are great things about Apple Music as a service.

From a curation standpoint, I really have found Apple selects tracks of high quality. From human-picked songs (like from the playlists shown above) to the algorithm giving me excellent music based on my listening habits. This felt very Apple-like and I have constantly been surprised at how good its picks were.

My wife and I discovered the breadth of country music for the first time listening to Apple's quality person-hosted live radio shows.

From an audio perspective, I actually prefer the quality of the music more than Spotify and the fact it offers lossless for free is amazing.

Positives like these make me even more disappointed that the product isn't easy to use.

In the end, the problem really lies in Apple not clearly defining what their product is. If the Music app is a successor to iTunes, it has unfortunately missed the mark because they’ve tried to jam in a streaming service (Apple Music) into a legacy paradigm. And if Apple Music was meant to be the focus, they didn’t let it shine as a standalone service.

One thing is for sure — Apple Music on the desktop has a lot of work to do if it’s to reach a level of decent usability.

What do you think?

Google Maps - Business Model and Usability

Cinnamon Agency — Wed, 25 May 2022 08:16:01 +0000

Nikola Petrović

2022-04-11

There are many things that Google Maps does right but it seems that they forgot how much focus you actually need to use their navigation while you are driving.

Why do we use navigation apps—particularly Google's?

The data from Statista shows that in the U.S. market in 2020, Google Maps was on top of the list according to downloads among other navigation apps on the market, followed by Waze. According to Comscore, Google Maps is currently the fourth most-used mobile app on a monthly basis. Verto and Manifest both show similar data where Google Maps is currently the most used navigation app, followed by Waze, which covers approximately three times the audience. And Apple Maps is behind Waze by a few percentage points.

The core purpose of maps is to make areas of interest searchable and easily findable for anyone that needs them. And when we find what we need, we use maps to optimize our trip to that destination with the quickest route.

Using digital maps gives us way more information than just how to get from point A to point B. We can use them to estimate and plan our trips, search for the nearest points of interest, and see an extended list of details for each of those locations. The fact that anyone can contribute to Google Maps' information brings about that social element of reading other people's reviews before deciding whether or not to visit a location.

Google Maps ecosystem

One thing that Google did with maps that no one could do something similar to was the creation of a whole ecosystem in which information is constantly updated by everyday users, no matter the geographic market. So the majority of the heavy work is done by the community and its users.

There are four sections to that ecosystem, which gives Google an advantage in bringing innovative features no other platform can match.

Navigational: The primary use of any map.

Informational: Information about companies, cultural places, and other places of interest.

Social: Writing a review or that moment of sharing bizarre footage from street view or satellite view.

Developmental: Providing a huge amount of data for research and development on other projects.

All of these four sections help in the circulation and updating of data that Google Maps has. That circulation of data is what makes their ecosystem so effective.

A small difference between search and navigation modes carries big problems.

For each of the above-mentioned sections, Google has special interfaces that provide all the necessary information, channeling each user to their own user flow. For example, the informational part of Google Maps is one of the most used by both desktop and mobile users, but on the other hand, the navigational part of the system is used exclusively by mobile users.

The mobile application primarily benefits drivers of passenger vehicles, although the application is increasingly useful when using public transport. No matter for what purpose we use navigation through Google Maps, we encounter the same problem, and that is that there’s more information than we really need. This is an exceptional obstacle while driving when the primary action we perform is driving itself.

HMI design is a design direction that stands for human-machine interface design. An HMI refers to any interface that helps a person complete a specific task using a machine where the display or control of that machine occupies a secondary focus, while his primary focus is on the job he is currently doing. And so some of the established rules in the car industry are that displays must have large enough buttons, must not have infinite scrolling (but instead should use sticky scroll), and perhaps most importantly, the amount of information must be limited to only the information that will help the user complete the desired action.

Therein lies the whole problem that Google Maps has, and that is the transition between the part of the application that offers information about the location of all important places on the planet and the part of the application where you only need to give important information about how to get from point A to point B. Both parts do what they need to do, but the transition in between is a design problem that needs special attention, and here are some of the most common current problems.

Extensive use of micro animations.

We are in the car, driving, and want to search for a location. Let's say a shopping mall. We would need to perform the following steps:

Search for what we need.
Wait for animation while the app loads full content about the shopping mall,
Select the CTA (Call To Action)
Run the navigation.

Now let's look at what is happening in an actual scenario.

The user searches for a mall by its name and selects one from the results list.
The user sees the CTA while the application is still loading the data.
Since loading usually lasts longer the user tries to select the CTA but instead of the CTA which moves up, the user selects the loaded content and opens another dialog with the CTA now in a new place.
Our CTA has moved 3 times and the user is still in the car, driving.

Actual scenario

Conclusion: the user's focus had to be changed 3 times to find the button. The solution could be for the button not to appear until all the information has been loaded.

Voice actions

There have been many complaints about voice-triggered actions, which is not a new problem, but it turns out that the Waze application, which is also owned by Google, has much better performance than Google Maps when it comes to voice actions, at least according to users.

Search options and recommendations

In Europe, a 67-year-old Belgian woman was led remarkably astray by her GPS, turning what was supposed to be a 90-mile drive to Brussels into a daylong voyage into Germany and beyond. Amazingly, she just patiently followed the computer’s instructions, instead of relying on her own common sense, until she noticed the street signs were in Croatian.

The road ahead of Google Maps

One of the oldest surviving maps is, ironically, about the size and shape of an early iPhone: the Babylonian Map of the World. A clay tablet created around 700 to 500 B.C. in Mesopotamia, depicts a circular Babylon at the center, bisected by the Euphrates River and surrounded by the ocean. It doesn’t have much detail—a few regions are named, including Assyria—but it wasn’t really for navigation. It was more primordial: to help the map-holder grasp the idea of the whole world, with themselves at the center.

Because of Google’s large pool of users and financial assets it can make more progress than anyone else. Street view as outdated as it is today is still one of the unique features no app is able to do as well.

But let's not give them all the credit simply because they have such large machinery going on that if someone makes a unique feature Google Maps will be able to make it present in their app in no time. That is how they got the function to live report problems, traffic jams, or police on the road while in navigation mode.

They are currently implementing a driving mode that would allow users to more easily use all the necessary options they have in the information section once they can enter the navigation when they can search all locations. It seems like it should be two separate apps, one with all the information and one with navigation but it is certainly unreasonable to keep them separate when all you need is for the right information to appear to the user at the right time. There are many edge cases as well as ways to use Google Maps but Google Maps is definitely one of the best examples of how design can prioritize information and establish a clear hierarchy.

An Introduction to API Testing

Cinnamon Agency — Wed, 27 Apr 2022 13:06:43 +0000

by Mateja Juričić, Manual QA Tester
Shared first on https://cinnamon.agency/

API development is already a crucial part of the industry. Now, API testing and engaging quality engineers is becoming increasingly important.

Working on APIs is becoming an increasingly important part of the industry, with quality being the top priority of leading organizations. Consequently, API testing is proving to be an integral part of API development, involving not just developers, but quality engineers as well.

These days, whether you build, test, or use everyday applications, you are probably using an API. And it’s not only customers - more organizations and businesses than ever rely on APIs for their products and workflows. APIs are the foundation of communication and data exchange - the interface - between our applications. If this communication breaks or doesn’t work as it should, that threatens and frustrates the whole chain of people and processes that go with the business of building an application. As evidenced in Postman’s State of the API 2021 report, both businesses and developers are focusing on APIs in order to speed up development, reduce failures, and ensure quality and reliability. Making sure your or any API you’re using works properly has become one of the most important parts of application development.

Development priorities for development teams and organizations
Source: Postman's 2021 State of the API Report

This brings us to API testing. API testing is essentially that: testing the functionalities of an API. But because of API’s role, testing APIs often includes testing an app’s business logic and end-to-end testing.

Usually, when we think of software testing, we’re thinking of UI testing following the traditional waterfall approach - a QA engineer tests the whole application at the end of the development cycle. This can be a very time-consuming and costly process that cannot guarantee that all bugs have been found, fixed, and that quality has been assured - especially when it comes to the middle layer between UI and the database (in other words, the API).

In the age of agile and continuous development, testing early and finding bugs early speeds up the whole development process and produces more reliable code. The sooner the issues are detected, the less effort and cost it takes to repair them. As API can be tested even while UI is in development, many bugs that are usually detected on UI can be found and fixed early on, which ensures that further development runs more smoothly - and ultimately saves time.

Testing is an important part of API development
Source: Postman's 2021 State of the API Report

API testing is often considered to be the same as unit testing, and as such we imagine that it is the developers’ job to test them. But API testing can be more than that. While unit testing focuses on isolated units or modules, API testing is part of integration testing which validates the business logic of an application and includes multiple components between the UI and the database. As it is the QA engineers and testers who have to have a complete view of how the interface is going to be used, they are the ones who are increasingly performing API testing. Understanding customers’ needs and looking at the system as a whole ensures the quality of the final output of the system, including required business rules and a complete user experience.

“It’s not just developers who work with APIs”: Quality engineers are increasingly working with APIs
Source: Postman's 2021 State of the API Report

API testing can be performed both manually and automatically. As APIs lack a GUI, the main idea behind testing APIs is to ensure that the communication between different levels of an application works fine. This communication is established via API endpoints and requests or calls that return certain values. These elements are what testers ultimately focus on. Common API test cases include, among other things, checking API return values based on input conditions, verifying that API is returning any type of data, verifying whether the API triggers some event or calls another API, and verifying if the API is updating relevant data. Bugs that are usually detected during API testing include failure to detect errors, missing functionalities, reliability and performance issues, API response time, incorrect handling of valid argument values, and incorrect response data structure.

When testing APIs, a wide variety of testing practices is used
Source: Postman's 2021 State of the API Report

This blog post outlines what API testing is in general and how focusing on APIs can help improve the agility and reliability of development and ensure the quality of your final product. Stay tuned for the next blog post with an introduction to API testing using one of the industry’s leading tools, Postman.