Welcome to the second installment of The ELTjam Lexicon of ELT in the Digital Age. You can read more about the series here and see the full list of terms we plan to cover here. This week, we’re finishing off the ‘A’s.
A-ha moment
No, not that A-ha moment. This a-ha moment is when a user understands your product and realises why it would make their life better. It’s a big part of the onboarding process (getting users into your product) and also contributes to user retention (keeping users once you’ve got them). It’s commonly accepted that if you can’t get a user to the a-ha moment, they won’t use your product, and this is a problem for big products as well as small ones. Twitter, for example, struggles with its a-ha moment. People understand it quite quickly but can’t figure out how it would make their life better. During live user testing of our vocabulary app Flovoco, we always spot the a-ha moment. It’s the first time the user realises that each level of the game focuses on a different aspect of knowing a word in English. Level 1 is meaning, level 2 is sound-spelling relationship, level 3 focuses on collocation and level 4 on derived forms. If a user doesn’t make it past level 1, there’s no a-ha moment, but if they do, they understand instantly how the app works and how it might help them. The trick lies in getting people to the a-ha moment as quickly as possible – something we’re still working on.
API
A tricky, technical one, this. Does it help to know that it stands for application programming interface? Or that it collocates with call? Probably not. What about a Wikipedia definition: ‘a set of routines, protocols, and tools for building software applications’? Let’s try a real-world example. Google makes the API for Google Maps available to developers, which allows them to make apps that use Google Maps. So if you use apps like Uber or Citymapper, you’ll notice that they use information from Google Maps in the app. Each time the app needs that information, it puts in an API call to the Google Maps API and gets the data it needs. A great example from ELT is dictionary data. Cambridge University Press offers APIs for its English Learner’s Dictionary, as well as dictionaries in lots of other languages. They charge a fee, of course, but if you’ve got a great idea for an app that uses dictionary data in an interesting way, it’s certainly something to look into.
App
We’ll assume that most of our readers know what an app is, although there may be some confusion over web apps vs. native apps. We’ll cover those in later posts, but this three-part primer from Lindsay Rattray is a good place to start. Instead, some interesting app-facts:
- 99% of apps only get used once. You’ll hear this stat bandied around quite a lot. Actually, the figure comes from BlackBerry and is about BlackBerry apps. Who knew there were BlackBerry apps…?
- The average session length (the time a user spends in an app) varies wildly by app category. The most engaging apps? Music, with an average session length of 8.9 minutes (so about three songs). Social media comes in fairly low at 2.5 minutes. Education apps don’t even figure in the top eight, which means the average session length is less than 2.5 minutes. (Our app Flovoco clocks in at 9.22 minutes, which we’re pretty chuffed about!)
- Google Play gets 60% more downloads of Android apps than the Apple App Store does of iOS apps. However, The iOS App Store generated over 70% more yearly app revenue than the Google Play Store (source). That means that if you want to make more money from your app, you’ve got more chance on iOS. You might get a slice of the $10 billion of revenue that developers made in 2014.
Asynchronous
‘Not happening or done at the same time or speed‘ and used most often in ELT contexts to describe the online component of blended learning courses. The alleged a-ha moment in blended learning products is when learners realise that the asynchronous element of the course means that they can study at their own pace and fit their learning in around the competing priorities of work, family and leisure time. What I’ve never seen is evidence that learners actually value this (if anyone has any research that points in this direction, please do let me know). The fear for providers of asynchronous self-study learning products is that what keeps learners engaged in their language learning is actually the synchronous element, which by its nature is more social and provides some kind of extrinsic pressure to attend. It’s like going for a jog on your own vs. going to a spin class. How many people do the latter because it’s the only way to ensure they do any exercise at all?
Authoring tool
In a 100% print ELT product, the authoring tool is usually Word. Nice and easy for everyone involved. In a digital product, the process of getting the author’s content into digital form seems to be much harder than it should be. Some publishers and EdTech companies use a back-end authoring tool that allows the writer to enter content directly into the platform (and usually see what it looks like straight away). These tools vary massively in quality and user experience. English360‘s is straightforward enough to use, as it was designed for teachers to create their own content. The one we use for Newsmart is an absolute joy, probably because it was built by a development team who had never seen an authoring tool before, so weren’t hung up on how they should look and feel. Most big ELT publishers, however, have decided that authors and editors shouldn’t be allowed to work directly with authoring tools, so use a complex system of Word templates and data entry companies. In the era of WYSIWYG authoring tools for blog platforms like WordPress, it feels positively antediluvian.
Coming next in The ELTjam Lexicon of ELT in the Digital Age: backlog, backlog grooming, badges, batch size, beta
[box]ELTjam offers a range of in-person and online training courses for ELT publishers and EdTech companies on all aspects of digital product development. For more information, contact nick at eltjam dot com. [/box]
Who knew that definitions could be so entertaining to read?!
Authoring tools are interesting. I’ve worked with both Word templates, in which I entered content following an XML set of rules, and that then got sent to a design team (note the word ‘team’!) and also with authoring tools, as a writer and editor. Although there’s a huge advantage to being able to see what your learning object is going to look like on-screen (in that you can gauge how intuitive it’s going to be, spot navigation issues, etc.) – my personal preference is to use Word templates. Why? Because the authoring tools that I’ve used aren’t simply requiring the writer to enter text. You need to format pages and search for photos and play around with where they are going to go and what size they’ll be etc. You need to embed videos and upload sound files. Two issues here. First, the writer suddenly has to do an awful lot more for their fee. Second, we’re asking writers to get learning objects to look as sharp and professional as those that are produced by qualified design ‘teams’ i.e. we’re suddenly asking writers to be designers as well… Given that ELT writers are necessarily qualified teachers too – that’s quite a skills-set!
I really like this series – great idea!
You said:
“Most big ELT publishers, however, have decided that authors and editors shouldn’t be allowed to work directly with authoring tools, so use a complex system of Word templates and data entry companies.”
Is this true? I haven’t been asked to write/edit in Word templates rather than directly into an authoring tool since 2007 and can’t believe people are still doing this! Worse still, unless I’m misreading you, it sounds like you’re saying that ‘most big ELT publishers’ have tried allowing authors to work in authoring tools and decided to go back to the old ways. Why would they do that? Which publishers? Thanks!
Hi Diane,
The situation is much more nuanced than is allowed for in brief lexicon definitions. A number of publishers probably owned their own authoring tools in the days of Flash, but the paradigm format shift from Flash to HTML5 has meant that those older tools are now redundant. The cost of building and maintaining a new authoring tool can be prohibitive and hence there are big publishers who have to rely on the tools provided by software devlopers. These may or may not have a non-specialist authoring interface suitable for editors and authors; if not, then providing input through Word templates is a common strategy, and may be the only one that works. The different software devlopers also have multiple systems, often employing macros and parsers to feed an HTML5 engine, which can mean we have to format content in highly-convoluted Word templates that would be a nightmare to write into as manuscripts. And, you may find that some publishers use a mix of different authoring tools across a range of products, including ones with author/editor interfaces. So, there isn’t a single situation that can be summed up neatly, and in my particular context it would be more accurate to say that in most new projects it isn’t possible, whilst in a few small projects it still happens.
You asked why there might be a return to the ‘old ways’? This suggests that your model of writing directly into an authoring tool is better/more efficient than writing into a Word doc. Well, again, that really depends on the situation. Let’s break digital content creation into three categories: 1) reformating from print – taking, say, a print workbook and building it in HTML5; 2) writing new content exclusively for digital delivery; 3) writing content that is media-agnostic and can be delivered in print and/or digital. For model 1, then writing directly into an authoring tool makes a lot of sense. For model 2 it may also make sense, providing that you are certain you will never want or need to publish the content in any other format. For model 3, the direct to authoring tool approach makes no sense at all because you will need multiple workflows to publish in different formats. If your content is imprisoned within an authoring tool and exists nowhere else, then you are limiting its versatility.
As Kathryn has noted above, there are other reasons why authors might not write directly into tools. Some find it stifles their creativity – particularly if they are writing for multi-format delivery. Others find it time-consuming, and (again depending on the tool you are using) it might be much cheaper to offshore data entry rather than incurring a cost of £30 an hour for tasks that could include formatting rubrics in bold, resizing images, etc.
As a final point, I’d draw attention to large content management tools that serve as a central repository for content creation, archiving, versioning, whilst also providing a shared platform for editors, writers and operations team members to communicate and collaborate. These big beasts will support content exporting to InDesign for print publishing and xml output for digital. Expect to see a lot more of these in the near future.
Thanks very much for this, Brendan. I guess my scenarios fall into your categories 1 and 2 and that in your final para to a smaller extent. It’s useful to have this overview. I think I was thrown by the suggestion in the lexicon entry that publishers had made a decision not to *allow* authors to write directly into authoring tools. From your explanation, it sounds more like a case of publishers not being able to keep up with the switch to html5. Thanks!