Another dot in the blogosphere?

Posts Tagged ‘app

Last week the press claimed that a virtual reality (VR) application was “making pre-school spaces safe”.

While I applaud the attempt, I question its wisdom.

I am all for experimenting with technology and exploring possibilities, hence the applause. But with practical realities, limited budgets, and finite energies, I wonder if the creators of the VR application learnt from similar attempts in Second Life a decade ago.

History repeats itself. It has to, because no one ever listens. -- Steve Turner.

Just because the technology has evolved does not mean that human imagination, critical thinking, and research and reflective practice in the field have followed suit.

Just because you can do something does not mean you should. It could create wrong expectations. For one, the application is a simulation, but it is perceived as a game, at least to one interviewed student who said as much. For another, the simulation is designed to engage. That is the rhetoric in much of schooling now. Effective technology integration goes beyond mere engagement.

The simulation is rudimentary now, but it can improve. One clear improvement is how learners might be empowered to create by authoring environments. This is the more important application of VR, but the press relegated this to the end in a single sentence.

The hardest part of learning something new is not embracing new ideas, but letting go of old ones. -- Todd Rose (In “The End of Average”)

There is always some harm in trying to do good. Sometimes the harm is unanticipated and other times it is unseen.

The harm of overkill VR is that we will keep doing the same things differently and thus add very little value with the technology. This will add fuel to the fire started and maintained by naysayers. Then when better applications of VR (or any other technology) come along, the change agents face a fire wall.

Turnitin’s Feedback Studio needs some serious feedback.

Yesterday I shared how its web application, integrated into an institutional LMS, kept logging me out and had UI controls reminiscent of the 80s.

If its web application was unstable and finicky, then its iOS app was bare-bones and underwhelming.

Turnitin’s Feedback Studio

I was hoping that I could do on the iOS app much of what I could already do with the web application. I was disappointed early on.

As I accessed Turnitin from an institutional LMS (BlackBoard), I had to log in with an “activation code”.

According to the instructions (as of 10 September 2017), I had to first log in to the institutional LMS on my iPad, pick any assignment, and click on an information (i) icon to reveal a “Generate Code” button.

When I tapped on the button, nothing happened. I could not get a code with the iOS app.

Hoping that the code was not tied to a device, I decided to try this on my laptop. Clicking on the button using my laptop gave me the code I needed. I had to use this workaround because Turnitin’s instructions did not work.

The UI of the app is simple. At first I was disappointed that what I did not use was plain to see and what I really needed to use did not seem available.

UI of Turnitin’s Feedback Studio

What was clearly visible were tappable areas for a rubric, summary comment, voice comment, and similarity (matching scores to other artefacts in the database) at the top of the page. I did not rely on any of these.

I do not even use the scoring element because 1) I keep the marks elsewhere, and 2) the point of this assignment is for students to respond to feedback via a reflection and to incorporate changes in the next assignment. Provide a score and the learning stops (and the badgering for marks begins)!

The actual tools for providing specific formative feedback, i.e., highlighting, commenting, selecting canned responses, etc., were not obvious. There was no initial-use help on screen. Such a job aid is practically a standard feature from app creators who practice user-centric design.

Thankfully tapping on the screen a few times revealed the highlighting, commenting, and type-over functions. I managed to markup and comment on a student’s work. In the screen capture above, I pixellated the work (grey) as well as my comments, canned comments, and highlights (all in blue).

Highlighting was somewhat laborious as the app selected an entire line when I wanted to focus on one word. It was also not easy to select several sentences in a paragraph, but I suspect that this problem is common to apps that display PDFs.

As I was trying this at home where the wifi was fast and stable, the markups in the app synchronised with the web version almost immediately. A better test might be at a public hotspot or transport where the signal is less reliable. This would test Turnitin’s claim that any app edits would update the web versions when a reliable connection was established.

I am not sure I would recommend the app for processing class upon class of scripts. The typing of comments alone would be a pain. An external keyboard might alleviate this issue, but not everyone has one. There is also the option of audio feedback, but this does not highlight specific parts of an assignment.

I would not recommend this app to the paper and pencil generation. I would hesitate to do the same even to those who consider themselves mobile savvy. I would not want my recommendations to be soured by association with an app that feels like it is in perpetual beta.

I LOL’d when I saw this tweet. It was a moment of truth and connection. Ask adults around you and you might get similar anecdotes of this shared experience.

But however humorous, the observation is superficial. It is probably what drove people like Prensky to create the concept of the digital native, i.e., kids born with technology are savvy with it because they are wired differently.

What proponents of the digital native narrative ignore is that we are first wired to play and explore. Our instinct is to learn.

If the available technology was a stick and mud, a child as a curious learning machine would use it. Some mud and even the stick might end up in their face or mouth.

Today the technology might be the computer or phone. A child is the same curious learning machine and the computers or phones stick as well. That child is no more a digital native than the previous one was an analogue native.

I often tell adult participants of my seminars or workshops that they are sometimes more native with some technologies than their students and children.

Take the use of Facebook for instance. Most adults and parents my age started using Facebook before they had kids or before their kids started using it. The adults are more aware of the usage, nuances, and changes in Facebook than younger learners. They might also be wiser about what to share and what not to. The adults are the digital natives in that context.

That is one of the key weaknesses in the false dichotomy that is the digital native-immigrant divide. It does not take into account context of use. A better but less well known theory is the digital visitor and resident continuum by David White.

Whether it takes a comic or some critical reflection, I hope more people read about how the concept of digital natives does more harm than good. After all, we learn not when we reinforce something we already believe in; we learn when we experience dissonance as we play and explore.

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:

  1. My Account.
  2. Mobile usage.
  3. 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.)
  4. My number in the filter.
  5. The done button.
  6. 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.

Online order.

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.

Part of the McCafe app registration process.

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.

Nagging reminders by the McCafe app.

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 McCafe app thinks my phone is

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.

Two-step verification of QR code in McCafe app.

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.

Bonus lesson
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.

Snaapp app critique 1.

Screenshot 1: 

  • This is an example of the app’s blocky and monotone design.
  • Note its poor use of English.

Snaapp app critique 2.

Screenshot 2: 

  • 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.

Tags: , ,

http://edublogawards.com/files/2012/11/finalistlifetime-1lds82x.png
http://edublogawards.com/2010awards/best-elearning-corporate-education-edublog-2010/

Click to see all the nominees!

QR code


Get a mobile QR code app to figure out what this means!

My tweets

Archives

Usage policy

%d bloggers like this: