Posts Tagged ‘app’
Last year I outlined how the poorly designed McCafe app could be used to learn design principles. Missteps and mistakes are often the best sources of learning.
My StarHub is an app that I use to check my data consumption and it is a wellspring of lessons on how NOT to design a mobile app.
The app claims to let users customise what they see. Currently, there are four fixed cards and six selectable ones. The latter are selected by default.
One cannot actually customise as 1) there are fixed selections (including ads), and 2) if deselected, the optional cards return after restarting the app.
The people behind the StarHub app might have forgotten (or do not care) that the customer likes to customise. Perhaps they need to adopt a new custom and repeat it as a mantra.
The app also breaks the old web page three-click rule. This is the rule that states that a user should be able to find what they need within three mouse clicks. In the mobile app universe, this should be a one or two tap rule given the nature of the platform.
Once I open the app, I need to make six taps to know how much data I have consumed in detail. I need to tap on:
- My Account.
- Mobile usage.
- The filter option (I manage and pay for my family’s numbers and mine does not appear by default and I have no option to choose my mobile number as default.)
- My number in the filter.
- The done button.
- Data usage to view current usage.
The app offers a minimalist graphic on main page that looks nice, but 1) it does not always appear, 2) when it does, it sometimes happens after a delay, 3) it is not detailed enough for my needs.
All this puts form over function and the needs of the designers over that of the user. This makes for a terrible app experience and I am reminded of it every time I use it.
Designers of user interfaces should be familiar with the concept of user-centric design. I wish more were passionate about the practice of the same. This is particularly important for designers of educational apps, especially those that provide access to content and learning management systems. No one wants angry, frustrated, or anxious users even before the learning begins.
The thread that runs through my rant yesterday and today is how people talk smart talk but walk dumb.
Several weeks ago, I had an unpleasant dining experience. It gave me food for thought on why technology-led change in school flows slower than molasses.
I revisited an eatery that made some changes. One such change was a subtle one. There were QR code stickers on the tables which linked patrons to an online menu and ordering system.
The process was straightforward: Scan, select, order, pay, wait.
While waiting for our food to be served, I dealt with a technical issue on my son’s phone. It took a while to deal with because the problem was quite serious. I spent almost 20 minutes trying to troubleshoot the problem. I know this because my food order did not arrive and I checked to see why.
I walked to the counter staff and asked if there was a problem with my order. They replied that I not ordered because I was “just sitting there as if I was waiting for someone”. Forgive me for doing what customers do, i.e., order and wait.
They also said that they tended to rely on online orders at lunch when things got busy. Apparently I was supposed to know this. Forgive me for not being a mind-reader.
A staff member then reluctantly pulled out a previously hidden iPad and saw the order. Almost as soon as she tapped on her screen did a confirmation appear on my screen. Forgive me for not reminding you to check your ordering system.
I am sorry. I apologise for the portion of the human race that holds the rest back because they cannot overcome their inertia and bias. They do what is good and comfortable for them instead of focusing on others.
I am not sorry. I make it a point to create dissonance. I tell and show people — teachers in particular — why and how to teach better with technology. The process is sometimes painful and difficult, but we do this because we focus on our learners.
Most of us would not put up with shoddy service at an eatery. I cannot put up with schooling that pretends to be education. I see through the lip service and push or pull people along if necessary. If this makes them feel uncomfortable, then so be it. Better to be honest than a hypocrite.
No, it is not a new word. I call a mobile app experience, particularly a bad one, an apps-perience.
I share some thoughts on using a commercial app by McCafe in Singapore. I hope to illustrate how edu app designers might learn from the negative examples McCafe has generously offered.
I provide screenshots from an iOS and Android phone because I used both to make sure that the experience was consistent. It was consistently bad.
Lesson 1: Bare-essentials registration
Most apps require user registration. The McCafe app requires your name, gender, full date of birth, email address, and phone number. As it only requires your phone number to tie the app to you and to send an SMS verification, this is the only data it actually needs.
It collects more information than it requires and this tells you that it wants your data for more than just providing you with a good deal. You are the deal for McDonald’s and its third party allies.
If you use this app, be sure to deselect all the options under the Personal Data Protection Act (PDPA) section. If you are lonely and like spam, select them all.
The registration process feels unnecessarily long, burdensome, and intrusive because of the amount and type of information it seeks. For example, it could have left out the date of birth details while including the age declaration option. After all, there was no way to verify a user’s age.
For that matter, there was no way to check the user’s name, gender, or email. If establishing identity is the purpose of registration, the phone number is enough. After all, our phone numbers are already tied to our identities when we sign up for mobile subscriptions.
The lesson for edu apps designers is the same. Respect the privacy of the user. If an edu user has an institutional ID number or email address, use just that. If not, get the bare minimum, e.g., email address, for setting up and verifying an account.
Lesson 2: Do not nag
When I start the app on iOS, I get this reminder. I cannot deactivate it unless I let the app notify me and allow it to track my location.
I choose to allow neither. All other apps I use stop nagging me once I choose no. This screen does not provide a “no” option and appears each time I launch the app. You can imagine how much joy this brings me. Not.
Lesson for edu apps designers: Reminders can be important, e.g., project deadlines, and you should give the user a choice to be reminded or not. If so, the type of reminder should also be an option. These reminders can be built into the OS, e.g., app badge, notification area, slider, or popup. Alternatives to these might be a reminder feed to a calendar, email, or messaging app.
Lesson 3: Mind your language
After the nag screen, I get this warning message (see screenshot below). This is two unwanted reminders to tap on before I can start using the app.
The McCafe app thinks that my iPhone is jailbroken — the app prefers jailborken — even though it is not.
The only good thing about this message is that I get a chuckle every time I see it.
Maybe the app developer has Scandinavian roots. Maybe there is a sneaky collaboration with IKEA for new line of toddler barriers, Jaīlbørkën. You heard it here first.
Lesson for edu app designers: You might not be providing an English learning experience, but if that is the language of the app, use it properly. No “borken” English, please.
Lesson 4: Put the user experience first
This lesson is hard to describe with a screenshot because it is the process of using the app to 1) claim stamps (five add up to a free drink) or 2) use coupons. Both use a QR code system that appears on the user’s screen.
The process seems simple enough. Pull up a QR code that identifies you or the coupon, then scan it. The problem is that the setup is designed for the cashier and not the user.
Every other app interface I have used that requires a user-generated QR code allows the user to align the code to the reader. This is like tapping your EZ-link card to the reader.
However, at McCafe the reader is positioned so that you cannot see where you are aiming the QR code app; only the cashier can. I experienced this for myself and I watched people after me doing the same thing. Each time the cashier had to guide the user’s hand left or right, up or down, and forward or back.
This process is even more awkward when you have to use a coupon because you have to scan the QR code twice. You try to scan it the first time. You then have to tap a “Next” button on screen for another QR code to appear.
When you do this, you have to turn the screen towards you, tap the button, and start aiming again. Watching a line of people do this can be mildly amusing if it did not look so stupid.
Lesson for edu app designers: Do not make your users feel stupid or make them do stupid things. Your users have experienced other apps and quite a few of these will feel slick or even sophisticated. Those other apps are no less secure and it is no shame to learn from other app makers.
This app rant is not about getting a free cup of coffee or poking fun at a mega corporation. One cup or small pokes are not going to make a dent in a company that used to have a clown for a mascot and now aligns itself with the passé Angry Birds.
This is about learning not just from a textbook or highly theoretical principles. With keen observations and critical questions, educators can deconstruct and reconstruct lessons from everyday phenomena.
Such lessons bring fresh perspectives to old issues and are fun and meaningful to the learner. That is the most important lesson of all: It is more about the learner and learning, less about the teacher and teaching.
Have you ever wondered what mobile apps might look like if they existed in the 1990s?
I got an answer when my son’s school authorities provided a notice for parents to download a “notification and attendance” app.
If you cannot remember what web pages looked like in the 1990s, this rude reminder might help.
The app reminded me of the web-based Java applets of old. It was plain and perfunctory. If the app could have an odour, it would be that of a musty attic or a mouldy basement. If it had an introductory screen, it would be to swipe cobwebs from its interface.
That is my way of saying it was unappealing. It was as if the app maker resented creating it.
The app was awful in form and function:
- It constantly nagged you to log in.
- It looked like it was ported from a desktop for point-and-click instead of swipe-and-tap.
- As a phone app it was meant for portrait use, but it seemed to be designed from a landscape point of view.
- It seemed to have borrowed its layout from a backward webmail programme. (Cough, iCON, cough!)
- The designer might have taken paper prototyping too seriously. The layout and buttons look like paper outlines and stickers.
I share two screenshots and offer more specific comments with the examples below.
- This is an example of the app’s blocky and monotone design.
- Note its poor use of English.
- The tappable icons or hotspots are inconsistently designed.
- The notification is incomplete: Saved to what location?
- The landscape photo is saved in very low resolution as a portrait with black letterbox bars.
Local app makers need better design sense. For example:
- Visual design: The look and feel should be modern or at least current, not a throw over from the Geocities web page era. A tight review of the five most popular communication apps should reveal a mountain of design clues.
- Usability design: The mobile app should be a dedicated app instead of a wrapper of a web app. Good apps focus on what the user wants and needs, not on designer or desktop hangups.
- Social design: A communication app should be designed for people to interact. It is not just for one party to disseminate. Users expect to be participants and to provide feedback. Build and promote those affordances.
- Current design: Today’s design is flat and avoids skeuomorphism. Instagram recently changed its Polaroid-like camera icon to a modern, flat icon. Old design is like Microsoft clinging to the diskette “save” icon even though no one uses diskettes anymore.
- Language: An app can look gorgeous and be user-friendly, but if its prompts are in broken English, its design is broken. This is not nitpicking; this is about taking pride in work.
Old and complacent design encourages old and complacent practice. Perhaps this is a strategy the app provider is using with schools. It looks safe and familiar to decision makers, so more schools might adopt it. But the app makers ignore other stakeholders and users at their peril.
I get that this image tweet is an opposite play on apathy (app-athy, haha!), but does it make sense?
I realise that there is a movement to promote apps. I have also met many people whose knee-jerk reaction to any issue, even complex social ones, is an app.
Have people reflected critically on what apps are, how we use apps, and what apps cannot and cannot do?
What kind of app is empathy supposed to be: Gaming, social media, productivity, utility, augmented, fantasy, etc.?
How do we use such an app? Do we activate it only when we need it and follow a checklist? Do we close it when we do not need it? Or is the app intelligent enough to know when to pop up and remind us to be empathetic?
Do we have a home screen full of other apps like being professional, critical, creative, or considerate? Can values and behaviours be codified as apps? Can these “apps” be externalised and disowned?
Are they available in different app stores? Is there quality control? Do they come with regular updates?
Is the empathy app free, freemium, ad-supported, or paid? If the app store is not empathetic to app creators and changes policies, will the app change to meet the circumstances?
I really do not know what “Empathy is the app” means. Perhaps my human OS need upgrades and my home screen needs more apps. Perhaps the empathy app creators need to make a “multiple interpretations” or “Empathy for Dummies” app.
Footnote: Here is something for the app-oriented to do before or after you read this. I recommend you first install the sense of humour app, interpreting double meanings app, common sense app, and listening app. If your OS cannot run all the apps simultaneously in the background, you are screwed.
Yes, screenshorts. Not just screenshots.
Screenshorts are images of text, images, or whatever happens to be on your device’s screen. The Buzzfeed article embedded above describes screenshorts as a way to overcome Twitter’s 140-character limit.
This is a sociotechnical phenomenon. There is a technical barrier (the character limit in Twitter) and a workaround (you can embed a picture of practically anything in Twitter). A few people started embedded pictures of longer form text and more people adopted the practice because it worked.
I use this strategy to provide a hook, summary, or concept bite of a larger resource I share. It might help to think of this as serving up a movie trailer and a direct link to the movie.
My favourite tool for creating screenshorts is OneShot because it allows cropping, highlighting, and auto-finding the URL of the article. The last feature is not always accurate and you have the option of using the URL copied to the clipboard.
However, the problem with screenshorts is that images in Twitter do not help the visually-impaired. While we have optical character recognition (OCR) technology, it does not seem to have extended yet as a web or mobile standard.
So a solution that helps many seems to have become a problem for some. But that problem is an opportunity.
The maker of OneShot suggested that screen readers for the visually-impaired be further developed to include OCR of screenshorts. That could be a parallel effort alongside a longer term solution of web and mobile standards to decode and tag screenshorts.
In the meantime, there is already a commonly employed workaround. Instead of just taking screenshots, sharers also include a link to the original source. This is not a solution in that the original source is larger than the shared selection. But it is a workaround in that a screenreader is likely able to process the original source.
As with most things, technology outpaces human readiness. It is important to realize that we invent the technology and we create the problems that arise. But these problems might be opportunities for even better work. We need only treat them as such instead of complaining.
I very rarely use my blog to endorse an app, particularly one that is not directly related to educational technology.
The app is very accomplished for one that seems to be a mail app at first glance. It is also a sorting and scheduling app.
As an email app, it is better than the stock app in that you can sort email by what is unread, is flagged, or has file attachments. You can short swipe to archive email or long swipe to delete it. You can tap and hold items in the inbox for quick actions.
You can access your calendar (mine is GCal) straight from the app. Acompli handles schedule invites by letting you know if there are conflicts with existing appointments.
When you compose new email, you can also schedule an appointment, provide your location, and attach photos or other files.
Best of all, you get the app for nothing. It is free. This gives us the collective permission to wonder how the app company expects to monetize it, if its efforts are sustainable, or if some other larger fish will come along and gobble it up.
That aside, I should point out that I have not been asked to promote this app nor am I gaining anything from the company by extolling the affordances of Acompli.
The app seems to be very well thought out with a clear user-centric focus. The people behind it seemed to not just problem-solve but also problem-seek. And that is something we can all practice in our bid to be better than we were the day before.