A year earlier, Joel Spolsky, who had helped create Visual Basic and was a project manager for Excel, had written an article saying that Microsoft had lost the API war, and that the Web makes the operating system irrelevant.
Then, of course, the iPhone happened.
In the beginning it wasn’t much of a threat to the web. On the contrary; it lacked support for a native apps API, and developers were advised to create web apps for it. But a year later Apple came out with the iOS SDK and store, and the first Android phone was released, along with its own SDK.
Developers went nuts writing native (that is, non web) apps, and in a few years there were half a million applications for the iPhone alone (nowadays there are over a million).
The iTunes store proved to be a multi-billion market, and the Android store, albeit with a slow start, followed on.
To some, this explosion of native apps was just a fad. The web is open, standard, accessible to all, etc, was their reasoning, so it will sure win, like the PC and Windows won over Apple in the eighties and nineties.
They were neglecting a few crucial details: Apple came back in the noughties (00’s), took over all the profits from personal computing and left the commoditized PC market in crumbles (see IBM selling to Lenovo, Dell getting irrelevant, HP leaving the PC business, etc).
So the “open PC” wining over the “closed Mac” story of the nineties is now the inverse of how things finally turned out.
The other thing is that since the time the web triumph was ascertained, mobile happened. And the web is, well, not as good in mobile.
Using JS for CPU intensive tasks eats into the battery like there’s no tomorrow. All kinds of built in phone features and sensors lack a web accessible API.
And some things, like video, image and audio editing (which is something lots of apps have to do under the hood) takes ages or is impossible to do within a web app, especially with all the constraints mobile browsers impose.
Plus touch interactions are just more fluent and fast on a native app. And you can also use them when there’s no good coverage, or even no coverage at all.
Now, if you think that all those will be overcome soon, as mobile devices get more powerful, with larger memories and faster CPUs, think again.
The trend might in fact be the exact opposite, as wearables, like the iWatch and similar offerings from Google, Samsung, Peeble etc, come into the market, with even smaller CPUs and less battery capacity.
So, is the web doomed? Well, not necessarily.
For one, we might use mobile devices more, and use them throughout the day, but in the end of the day (pun intended) it’s the desktop (which nowadays pretty much means the laptop, but I digress) where we do our important and productive work.
A phone, a tablet, or a wearable watch, is not exactly were we prefer to edit documents, organize files, and do our business. And in the desktop computer, the web shines, and browsers are on par with most native apps.
Second, the web is not just HTML.
Or, to be more precise, what we most like about the web it’s not the exchange of html documents, but the ability to connect to external services easily and without having to manage our computer and programs or care about viruses and crashes.
Modern mobile apps offer that too.
They are essentially clients for web services (e.g the Facebook and Messages app for Facebook, the Google Maps app for Google Maps, etc). The fact that they use native code instead of html doesn’t make them less capable; in fact it makes them faster and slicker.
And as for the headache of managing our computer, modern apps make this a thing of the past.
They install with one click, uninstall just as easy, and save our data in the cloud for easy sync. You don’t have to play the “admin” for your iOS or Android device.
Third, even on mobile, some things work better as web apps. Newspapers and news sites for example are better accessed from the mobile browser compared to installing myriads of different native app clients for NYT, Guardian and the tons of other sites.
Apps heavy on collaboration, where users spend most of their time in the web interface at home, also qualify for this (this is were most LMS platforms fit in, as the extra real estate a laptop affords makes it much easier to work and study using them compared to a mobile device).
Mobile learning, save for specialized methods like flash cards, is nicely served by web apps. Having the same exact experience you have where you most use the app is preferable to having to learn two different interfaces.
And of course responsive web design makes fitting into the different screen sizes even easier.
So who’s gonna win? For the short to medium term, we bet on both. Mobile isn’t going away and isn’t a fad, and the web is not going away either. So hedge your bets ladies and gentlemen, and grab the popcorn.
Creating anything is an exercise in balancing ideals with realities, or ambition with available resources. Of course software, especially internet enabled software, is a multiplier of our resources, in the sense that one man with an LMS platform can build a fully functional online school catering to thousands of students.
Still, building a successful online course is all about making the right compromises and using your available resources with the appropriate restraint. As a e-learning course creator you have to learn to balance between size (scope), cost, and time, and this is what this mini post series is all about, beginning with…
Cost might seem like an easy thing to manage. After all you have a limited budget, and you have to work within that, what could be easier? Either you have money in the bank or not. Still, the number of projects (e-learning or otherwise) that go over their budget is surprisingly high, as in practice there are a lot of details and variables that can throw you off course.
Managing costs is all about estimations. If you have good initial estimates and keep tabs on subsequent spending you are all set. That’s, of course, something that’s easier said than done. If you are a large enough organization to have budget specialists and accountants, you can refer to them for help, but if you are a small shop, it’s by no means impossible to do it yourself.
For starters, don’t just do some quick mental estimation or some napkin calculations and call it a day. To get a proper sense of what the development of an e-learning course will cost you, open your copy of Excel and note down everything that will (or might) incur an expense. Do that early in the planning stages for your course, and keep it updated as requirements or scope changes.
Some of the costs would be obvious and come easy to you: educators running the course and technicians supporting your infrastructure would have to be paid. Others, not so much. Some one-off costs related to course creation that you might miss, are:
– costs for licensing educational material, videos, etc.
– costs of employing someone to write a course’s material.
– costs of employing a graphic designer/illustrator.
– costs of translations / transcripts / proofreading of material.
– PC software and hardware costs
– costs for broadcasting equipment (cameras, microphones, headsets, etc)
Whereas recurring costs might include:
– Web hosting costs
– Software license renewals / updates
– renting physical space for class meetings (in hybrid learning scenarios)
– support desk costs
– internet service provider (ISP) costs
– backup costs
Some of these costs can be shared among several courses (e.g hosting all of them on the same server if your student count is low enough to permit it), whereas others have to be paid in full for any additional course you create (e.g. the salary of the educator running the course).
After you’ve created a few e-learning courses you’ll have a pretty good grip on the costs associated with creating a new one, but keep an eye for any specialized requirements a new course could have that might throw you off budget. For example a hybrid course offering some lab time will obviously need lab space and equipment, and thus will cost more than a purely online course. Similarly, some online course might need you to license a specific software package or LMS plugin (e.g a course on hardware design will require a Verilog tool).
Your expenses will look very different depending on your intended size and scope. A course designed to accommodate 100 students doesn’t have the same logistics as one designed for 100,000. Know your scope and estimate accordingly.
One common mistake of those running e-learning as an online business is trying to scale their e-learning offering too quickly. If you’re still testing the waters, start low. As you get more users (something that might take years or even never happen), you can improve your infrastructure as needed.
Having far more paying customers than your initial LMS setup can stand is what we call in the business, a “nice problem to have”. Your students can take a little downtime as you upgrade your LMS deployment to accommodate them, but your bank account can’t take a premature hit based on an overly ambitious business plan.
Your initial estimates of the expenditures involved and the total cost paid can turn out to be widely different amounts. Not just because prices and renting fees are not set in stone, but also because unexpected expenses occur all the time. Your budget for two $2,000 web servers, for example, might have missed the $300 setup fee per server, the $200 courier service bill for delivering those servers to your premises and the $50 of cabling needed to connect them to your network.
The only way to not go over-budget is to update your initial estimates often as new developments and costs appear. You’ll also need to set aside some budget for all those unexpected costs in your initial planning (if you you don’t end up needing it, that’s fine, but if you do then this precaution will save your bacon, so to speak ― especially if you have to justify any new expenses to some stingy boss).
Cost management goes hand in hand with managing the scope of what you build.
If your budget turns out not to be enough don’t give up. Just scale down. Perhaps your initial estimates were overly ambitious. Perhaps (as we discussed above) you don’t need such an elaborate setup at this time.
Some things are necessary for a fully functional e-learning deployment, others are secondary or luxuries. We’ll cover the art of knowing which is which, or “managing scope”, in the second installment of this series.
See you next week!
The post E-learning course development: How to balance between size, cost and time? Pt. 1 appeared first on eFront Blog.