How Big Data and Mobile Startups Are Changing Education

October 9, 2013 Leave a comment

This article was originally posted in Cisco’s Technology News Site and is republished with the permission of http://thenetwork.cisco.com/

Anne Field

October 06 , 2013

Recently, there’s been a notable increase in startup accelerators aimed at incubating educational tech companies. The first, Palo Alto, Calif.-based Imagine K12, opened for business in 2011. Now a handful of others have appeared, from Kaplan EdTech Accelerator powered by TechStars, a three-month program located in New York City, to Pearson Catalyst, started by the U.K.-based educational publishing powerhouse. “There’s a realization that technology can dramatically affect educational outcomes,” say Tim Brady, founder and partner of Imagine K12.

The startups, themselves, are focused on a wide array of problems facing not just teachers, but administrators, parents and students, as well, using big data, mobile technology, and a number of other innovations. Here’s a look at three:

Data Mining As Easy as A,B,C

Five years ago, when he was the San Francisco Unified School District’s first director of knowledge management, Ben Glazer had a bird’s eye view of just how well–or badly—teachers, superintendents and others were using data to inform educational decisions. And what he saw wasn’t pretty. With a variety of fragmented data repositories throughout the district storing everything from demographic information to records of unexcused absences, “The systems were not in place to support strategic goals,” he says.

Glazer, along with Stuart Frye, a former Harvard Business School classmate, decided to create a system with which teachers could use classroom data to become better educators and founded a company in San Francisco called Eduvant to sell it. Three years ago, a year after starting the company, they were accepted into Imagine K12’s first three-month class.

Developing the product involved two steps. The first was finding a way to integrate all those disparate systems. Then, they added statistical techniques allowing educators to analyze and mine the data, collected in real-time, looking for relevant patterns.  That involved creating models able to predict student performance and notice when individuals deviated from anticipated outcomes. The bottom line: A middle school teacher with perhaps 200 students might be too over-loaded to notice when a child’s grades started to drop. But, using these tools and conducting data reviews weekly, or even daily, could change that.

Although the tools are designed to be intuitive and easy to learn, Eduvant recently introduced a free, online training system that takes 15 minutes a day for 15 days to complete.

Thwarting Cheaters through Data Analysis

As online schools and courses become more popular, there remains a thorny question: How do you, say, make sure the people who take an exam really are the students they purport to be? Or, at a more traditional school, in a room packed with test-takers monitored by a remote proctor, how do you stop cheating?

About three –and-a-half years ago, Tim Dutta, a management consultant and serial entrepreneur, and Rajnish Kumar, a researcher at Georgia Tech, who had worked on a computer visioning and video analytics project for the TSA, came up with a plan to address the problem. Relying on facial recognition, real-time big data analysis and other technologies, they would create a way to monitor cheating without the use of a human proctor. Trouble was, they were a bit ahead of the technology available at the time.

Then, earlier this year, they founded a company, Verificient Technologies in New York City and, last spring, were accepted into Kaplan EdTech’s first class. The basic idea works like this: Each school specifies certain parameters to be monitored—say, whether someone gets up from a chair or looks at a cell phone. Then, when students log into the system, it conducts a facial and knuckle scan to verify their identity (finger-printing is too expensive, according to Dutta). As soon as students start taking the test, the system swings into action, videotaping them and monitoring their computers. Then, through an algorithm allowing for real-time video analytics, taking 30 impressions per second, it provides a report flagging possible cheaters in red and suspicious activity in yellow. Officials can click on any questionable section and see a recording of what happened.

“We don’t make the final determination if there was cheating,” says Dutta. “The institution does.”

The partners now have about seven pilots in the works, including at Kaplan itself. They’re also in talks with potential customers such as corporations, which would use the system for employment verification.

Engaging Parents Through Mobile Technology

When Catheryne Nicholson’s oldest child enrolled in kindergarten five years ago, “I was shocked that nothing had changed since I’d gone to elementary school,” she says.  Nicholson, who had spent many years building large-scale systems for the Defense Department, among other places, couldn’t believe that something as seemingly straightforward as the school directory would be produced only in a paper version and would take six weeks to produce.

Last year, when her daughter entered kindergarten and nothing had changed, Nicholson decided it was time to act. She and a former colleague figured they could create an app aimed at the Holy Grail of education: parental involvement. “It’s the single most powerful lever you can pull to change educational outcomes,” she says.

The basic idea was to combine the power of mobile app technology and the influence of parents in their children’s education. They founded a San Carlos, Calif-based company called MommaZoo, applied to Imagine K12 and were accepted into a three-month-session earlier this year.

The app provides a centralized location from which parents, teachers and students can get access to all school-related material, from homework assignments  to requests for supplies (i.e., empty soda bottles for next week’s science project). So, instead of having notes from the teacher buried at the bottom of a child’s backpack, they can be sent to the appropriate section of the app. Another advantage: Updates can be made without involving schools’ over-extended, under-staffed IT departments.

The central component is the app’s contact management function. MommaZoo’s software not only hosts each school’s mobile directory online, but helps to create it, along with links for texting. Plus, there are such extras as the ability for teachers to share videos if, say, there’s a concept the students seem to be having trouble grasping. Schools also can use the app to make money by selling mobile ads to local vendors that appear on the directory. The app is in over 100 classrooms and two school districts.

Parents and Educators: Here’s How to Safeguard Kids’ Data

This post was originally published on EdSurge, an independent information resource and community for everyone involved in education technology.

If you’re an educator or a developer building and using cool technology to help teachers, children and parents, I’d like to give you a Momma Bear’s piece of advice: if you collect or store information about my kids, secure it. The minute you start gathering data about them, my spider senses start tingling. No matter how innocuous the data may seem to you, remember: these are my kids.

Much of the promise behind technology’s ability to help students is premised on collecting and analyzing student data. But if you haven’t seen the recent articles “Data Security is a Classroom Worry, Too” and “How Shutterfly and Other Social Sites Leave Your Kids Vulnerable to Hackers,” or heard what happened to inBloom, or know the revised COPPA rules took effect July 1st, pay close attention. With headlines like these, it’s hard not to question the ability of our schools to protect students’ privacy.

Everyone — educators, parents, and developers — needs to understand the fundamentals of data security and privacy. Before you use or build technology systems which contain information about kids, there are four basic areas to look out for: your browser, the network transmission, the application servers and the database.

1. Protect your web browser

Educators and parents: Do you use web applications to send videos, links or share information to a lot of kids? If so, you could be victimized by cross-site scripting (XSS). Fifty-seven percent of cyberattacks in the last quarter of 2012 were due to XSS, which occurs when malevolent HTML or Javascript code is inserted in a regular text field. What this means for kids, teachers, and parents is that an attacker can, without your knowledge, gain privileged access to content on the page, session cookies, and a variety of other information. How do you prevent this? Ask the developer who built the web application if they have protected their site against XSS.

Developers: Almost all web libraries escape data inputs when you use them properly. For example, in jQuery, use the text() and val() function instead of html(). This is only for values inserted in the HTML DOM. You will need to escape properly depending on context: HTML, script tag, event handler attribute (like onload) or in a URL. Protecting yourself against SQL injection is very similar, so do that as well.

2. Protect your transmission

Educators and parents: The next time you’re on a website which stores kids’ information, look at the address bar. Check if there’s a little lock icon or if the address starts with https://. The ‘S’ after the ‘http’ stands for ‘secure’ and indicates that SSL (Secure Socket Layer), a technology that encrypts all communications going over the Internet, is being used. If the ‘S’ and lock are not there, the site is not secure. Sometimes a web application will have the lock on the login page but not on others. If the site contains kids’ data, every page in the entire application needs to be SSL secured. It’s very easy to get a cookie that has been established on a private page from a public one visited afterwards.

Some schools block SSL in order to monitor what’s transiting through their network. School administrators: this is horribly misguided and you’re putting everyone at risk at your school.

Developers: SSL is cheap and there’s no reason why you shouldn’t use it throughout your site. If your SSL app is getting blocked by a school, explain to them why they should change their ways. If they won’t, provide an alternate insecure subdomain using distinct sessions. A common misconception is that the communication between your computer and a website is private. It’s not. Everyone on your network can see your traffic. Play with Cookie Cadger in a coffee shop if you’re unconvinced.

3. Protect your servers

Educators and parents: It only takes one server intrusion to get your kids’ data and hardening servers requires serious expertise. Ask the developer what measures have been put in place. The answer should be detailed, thorough, and address the areas of intrusion in this article. Beware if the answer sounds evasive or too simple, and ask someone who is more knowledgeable to check it.

Developers: You should understand the following: ssh setup and usage, strong password policies, minimal Linux distributions (remove X windows and all extraneous packages), how to keep server software up to date, disabling root login, iptables, how to set-up centralized authentication (like openldap), and the details of logging and auditing. Hardening servers isn’t trivial so if you’ve never heard of iptables, develop on cloud services such as Heroku and Google App Engine because they have done the hard work for you.

4. Protect your database

You may not be big enough to be the target of a high profile attack, but you may inadvertently expose your information in other ways.

Educators and parents, here are a few very common examples:

  • An application you register for sends your password in an email or mails it to you in a letter. No one, not even your school, should ever have your unencrypted password. If you lose or forget your password, the application should send you a reset link and never the password itself.
  • A common password is used with other teachers or students to access an information site. Never share a password. Period.
  • You keep a student directory copy on your hard drive or laptop. What happens if you lose your laptop or it’s stolen? This information should be stored in a secured place (e.g. Google Drive or MommaZoo).

Developers: Avoid keeping database exports on your hard drive, it’s too easy to lose. Salt your users’ passwords and hash them using robust functions, like SHA-2 or even better bcrypt (not MD5). Advanced crypto math is not required. Use common libraries such as jBCrypt in Java, bcrypt-ruby in Ruby, and bcrypt.js in Node.js, or even better, use a third-party sign-in like Google.

Conclusion

Protecting users’ privacy and security is a balancing act. Too much paranoia compromises user experience and is very time-consuming. But wanton carelessness jeopardizes our kids. Educators and parents, be proactive: don’t use unsecured systems and hold the technology company accountable to help protect our kids’ data.

Are Students Ready to Learn? Ask Their Parents.

March 15, 2013 Leave a comment

This post was originally published on GettingSmart, a community passionate about innovations in learning.

Parent engagement matters.
The research is undeniable that parent involvement in student academic success matters. It is more predictive than socioeconomic status by a multiple of 2 – 10 times (1). The benefits of parent engagement are vast: it not only drives academic performance but improves student emotional well-being, induces better student classroom behavior, and improves school attendance. It also benefits schools through fundraising and volunteering.

Since school-age children spend 70% of their waking hours (including weekends and holidays) outside of school (2), the opportunity for parents to reinforce classroom learning is significant, especially when kids are young. In fact, the earlier parent engagement begins, the more powerful the effects (3).

Traditional school communication outreach programs are antiquated.
The most effective forms of parent involvement are those that engage parents in working directly with their children on learning activities at home (4). While there is resounding acknowledgment in favor of parent engagement, the tools schools use – websites, emails, and paper – are woefully antiquated.

As a parent, the information on a school website or email blast is rarely engaging to me. It’s the classroom information that is of most interest: what my kids are being taught; how they are doing academically, socially, and emotionally; how can I help my kids’ teachers.

Language, socioeconomic barriers and lack of access are also problematic. According to the California Department of Education, 37.4% of public school students speak a language other than English at home, 23.2% of students are English Language Learners (ELL) and 71% of those ELL learners are in elementary grades.

In order to include ELL parents, classroom communications need to be translated into multiple languages.

However, we cannot expect teachers to do more than what they already do to engage parents. But we can ask technology to do more.

The key lies in using mobile technology.
Ask any parent what device they have with them the most: it’s their mobile phone. While computer access is still a challenge in some demographics, smartphones are changing the picture. According to the January 2013 Pew Internet survey, 55% of adults use the Internet on their mobile phones, nearly double from three years ago. Nielsen further segments smartphone ownership by ethnicity, which shows the adoption of smartphones by Hispanics, African-Americans, and Asians higher than Whites.

The bottom line is: if schools want to engage as many parents as possible, the solution must be mobile.

Conclusion
The two main actors in a child’s education are parents and teachers. The benefit of involving parents early in their kids’ classroom education sets the stage for years to come. By facilitating communication and connectedness between teachers and parents, mobile technology can change our schools for the better.

Footnotes:

  1. Walberg (1984) in his review of 29 studies of school–parent programs.
  2. Clark, R.M. (1990). Why Disadvantaged Children Succeed. Public Welfare (Spring): 17-23.
  3. Cotton, K., Wikelund, K., Northwest Regional Educational Laboratory, School Improvement Research Series. In Parent Involvement in Education.
  4. Cotton, K., Wikelund, K., Northwest Regional Educational Laboratory, School Improvement Research Series. In Parent Involvement in Education.

Are Start-up Accelerators Helpful?

March 11, 2013 Leave a comment

This article was first published on Women20.

It all started with a tweet from Paul Graham:

Imagine K12 is a start-up accelerator for education technology companies. Modeled after Y combinator, it’s an intense 4 month program featuring weekly partner reviews, sessions with high profile education entrepreneurs, and pitches to educators and investors.

Since MommaZoo is an education technology company, Imagine K12 seemed right up our alley. But before Paul Graham’s tweet, I never considered participating in an accelerator. I hardly fit the profile of the newly graduated college hacker that accelerator programs are designed for: I’m the mother of two, I’m way out of college, and I’m not male.

My co-founder, Matthieu, and I applied to Imagine K12 as a long shot. When we got the call offering us a spot in their winter class, we were too stunned to say anything other than “can we get back to you tomorrow?” For the next 24 hours, we debated whether an accelerator could really help us. A final gut check made us go for it.

We are now halfway through Imagine K12’s program. We’re happy to report that our decision was one of the best we’ve made. Here’s what’s been invaluable for us:

Your Baby is Ugly

Honest, brutal feedback from very knowledgeable, dedicated people is precious. In education, teachers are often too nice to tell you your product is terrible. They just won’t use it and you’ll never know why. Parents will give you feedback but it’s rarely tractable (we simply have too many problems) and scheduling time with them requires rotating the earth backwards. The continuous feedback Imagine K12 gives us has made MommaZoo immeasurably better.

Iterate. Faster.

Imagine K12 includes events (like demo days) that act as forcing functions to improve your product faster than you thought possible. Schools have rhythms that you must be mindful of. If you don’t iterate fast and time your product changes appropriately, you may miss those windows of opportunity.

Network Effect

When you’re a start-up, it’s almost impossible to get the attention of educators. Imagine K12 brings them to you, makes the introductions and validates your purpose. You meet luminaries and influencers in the field and learn from their mistakes and successes.

In the Same Boat

In education, a unique blend of consumer and enterprise models is necessary. This makes the start-up road even more challenging: EdTech is carving a new path. Having other entrepreneurs in the same boat to help, inspire and boost you up when you’re at your low makes a big difference.

More Women

Teachers and educators are mostly women and so it makes all the sense in the world for women to start Ed Tech companies. And yet, look at the number of women founders: it’s dismal (ladies, check out Edukwest and tell me what you see on their homepage. Can you believe it was started by a woman blogger?!) Now look at the number of women founders in Imagine K12’s portfolio: it’s a breath of fresh air.

What Imagine K12 cannot do (or any accelerator, for that matter) is give you the magic recipe to make your start-up succeed. You still need to find it yourself by working harder than you ever have and incrementing relentlessly.

Most start-ups fail. However, we have no doubt MommaZoo’s chances got better with Imagine K12 at our backs.

Categories: Uncategorized

On Security

December 20, 2012 Leave a comment

Picture by dzarro72MommaZoo takes data security and the Children’s Online Privacy Protection Act (COPPA) and Rule very seriously. COPPA prohibits against the collection of personal information from children under the age of 13. COPPA also applies to individually identifiable information about a child that is collected online, such as full name, home address, email address, telephone number or any other information that would allow someone to identify or contact the child. Data security is protecting data from being destroyed or accessed by unauthorized users. Because data security and COPPA are so important to us, we want to detail the measures we take to protect our users and our kids:

1. Password and data encryption. For any website where you enter a password or provide identity information into, always look in the address bar for the little lock or the “s” at the end of http. The ‘S’ stands for ‘secure’ and its presence provides the same level of security as your online bank account. We encrypt all connections in MommaZoo, passwords are salted (a technique to make them computationally prohibitive to decrypt), and all our data is secured in a protected database that’s backed up every 20 minutes. Backups are kept in a long-term storage that’s equally protected. Our encryption key (SSL certificate) is issued by certified third parties (in our case GoDaddy’s Secure Authority) and uses strong encryption (we use 256 bits certificates while many others only use 128 bits). Many sites, including class photo-sharing websites, are not encrypted and also contain a great deal of identify information. This means that someone can easily hack the user’s password and download everything, including entire class kids’ roster pictures and associated info.

2. Login protection. When you register in MommaZoo, your login and password are encrypted. This encryption key (called a cryptographic hash in the jargon) is the only thing we keep in our database. On each login, we also generate another key just to identify you for the session, until you logout. This allows us to keep track of your session and not login again every time you come back in MommaZoo while not compromising security. As your personal key can be invalidated anytime (it’s not tied to your credentials), all communications between your web browser and our servers are secured with HTTPS, providing a good mix of security and convenience.

3. Kid personal information. The reason we only ask for kid’s first name is to identify the parents only. We do not create a kids’ roster list. The basic contact info from parents is so they can find each other as soon as school starts, instead of waiting 3 months for a paper roster or PDF file to get published (and are outdated the minute they are published). Each parent maintains their own contact info and can specify the best email and/or phone number for the class to use. We want to enable parents to get to know one another better so that we can help each other, the class, and the school.

4. Pictures individual identification. Many photo-sharing sites default to “tagging” and require you to explicitly disable the feature. The reason we do not tag pictures in MommaZoo is because we do not want to explicitly identify which kid is who. And of course, pictures are only visible by your class and can only be downloaded when you are authenticated.

5. Group validation. Any postings (pictures, messages, files) emailed to yourgroupname@mommazoopost.com have a validation check that confirms the person is a member of the group and is allowed to post.

6. School membership validation. We implemented a code for select schools: you must know or be given a code to add yourself to any of the classes at those schools. We monitor groups that attain a certain number (groups with less than 5 members have little risk).

There is no system in the world that is completely impervious to malicious attacks, but we make sure we are doing everything we can to protect our users. Outside of MommaZoo, the level of security at school isn’t going to change by using or not using MommaZoo. A tight parent community, where parents know each other and are aware of possible dangers improves school security. This is what we’re trying to empower.

Categories: Uncategorized

Building MommaZoo as a Mobile Web App (part 2 of 2)

October 1, 2012 Leave a comment

This post is the second in a 2-part series that both relates our experience in developing MommaZoo on a mobile web platform and summarizes some of the lessons we’ve learned on the way.

As explained in my last post, building for mobile on the web platform and HTML5 has a lot of advantages. This doesn’t mean that it’s easy or for everyone. The application has to be a good fit both in terms of visual complexity and of how much data it needs to load. I’m going to outline some of the portability and performance challenges we’ve faced and how we’ve alleviated them.

Portability

After the first 2 weeks of development I thought “oh this looks easy: develop on the desktop and just check how it looks on mobile once in a while”. Until we started testing the broad spectrum of mobile devices our users have.

Mobile browsers have all sorts of quirks and you’ll quickly learn to hate them with a passion. The worse of all is probably the Android browser: we have all sorts of conditions in our code to handle it differently. Reload timing is different, parts of rendering are deferred for some reason, and it doesn’t even support animated gifs (are we in the 1990s?).

Mobile safari is not much better. It seems to change opinions on what to do about cookies and local storage every other version. Apple is “really big” on user experience and forcing people to retype their password every time is both user-friendly and secure (not). It also behaves differently if you open the site in mobile safari or through a home shortcut because it relies on a different runtime. I could go on and on and on…

On the testing side, everything could work perfectly. Until you try one more device. Both devices are on Froyo so they should behave the same you say? Not necessarily. Mobile vendors like to use different snapshots version of Android. And what’s the minor version or your iOS device? Testing can therefore become very expensive as you have to test everything on as many devices as possible and automation across all of those is impossible.

Now, the positives.

First, things are getting better. Fundamentally, mobile browsers are maturing at a very fast clip. What I’ve seen of Jelly Beans is very good so far and Chrome Mobile is consistent with the desktop version. Mobile Safari is also improving and the kinks are disappearing gradually. iOS 6 offers many interesting new functionalities for web development.

Second, and contrary to what I’ve read here and there, I’m very hopeful of the pace of obsolescence for older devices. Almost everyone gets a new phone after the end of their one or two years contract and the latest modern mobile browser comes with it. Tablets may change that a little, but so far Apple seems determined to not let people keep them for too long.

Performance

Mobile performance can be tough, users expect fast response times: more than 5s and you’ve lost. Yet you have to operate over lousy networks with bad reception. For example, the first school that has been using MommaZoo is tucked between 2 hills, making for very bad reception quality. Users don’t take that into consideration (and who can blame them). If it’s slow, your application will not be used.

So the three basic tenets of mobile performance are:

  • Make as few requests as possible. Tests have shown over and over that mobile latency can be really high. The edge network for example has a latency ranging from 150ms to 500ms. I’ll let you do the math with 20 requests.
    • Minify all your Javascript.
    • Prefer bigger files over a lot of small files. Merge your Javascript files and CSS files in just 2 big files. Except if they’re over 100k.
    • Sprites. Really. Just count the images on your page, you’ll see.
    • If you have a single page web app with XHRs loading content, don’t do that for your first page load. Render it as much as possible on the server (templates, backbone.js inlined collections).
  • Make small requests.
    • Gzip everything.
    • Use few and small libraries. Forget jquery, use Zepto.js or similar. Consider the cost of everything you use.
    • Trim down the data returned by your XHRs as much as possible. Your server should always return exactly what’s needed, nothing more.
  • Do your cache homework. The HTTP protocol has many caching options built-in. You need to know all of them as different resources will require different cache policies.
    • Images should be cached for a long time. If you change them, just use a different name.
    • CSS or Javascript files should rely on If-Modified-Since and your server should return a 304 when they haven’t changed. You still pay the latency price but remember, you should have a single CSS and a single JS file.
    • XHR data should either not be cached or use etags.
  • Cheat (yes, that’s the 4th point, that’s what cheating is about).
    • Execute requests while the user is just looking at the page. The best time is right after another request completed.
    • When using external APIs like maps or analytics, always use the async versions.

We’ve seen dramatic improvements using most of those techniques (in the order of 5x to 10x). But we’re not done yet, performance work is never ending. We have several ideas to reduce our load times even further, like caching slow changing data in the browser’s local storage and only ask for deltas from the server. The application cache is also interesting even though it comes with headaches.

Conclusion

All things considered, I’m very happy with our decision to target the mobile web. It may not work for everyone: if your UI is very involved and graphics intensive, you may want to evaluate your options a little more. Native development – if you’re targeting PCs (and you Mac users, are PC users despite what the Apple ads say), iOS and Android – is signing up for very high development costs. The web platform, even with its growing pains, is allowing us to stay small and nimble and for a startup like MommaZoo, it makes all the difference.

Categories: Uncategorized

Building MommaZoo as a Mobile Web App (part 1 of 2)

September 10, 2012 1 comment

This post is the first in a 2-part series that relates our experience in developing MommaZoo for mobile devices on the web platform and summarizes some of the lessons we’ve learned on the way.

We knew from the start that we wanted MommaZoo to be accessible from as many devices as possible and have the widest reach possible. We wanted parents to use it on their phone while on the go, for example inviting others to join them at the playground. But also make longer forms of communication possible, like class newsletters.

So while MommaZoo’s primary platform is mobile, which nowadays mostly means iOS and Android, we also wanted to be available to laptops and desktops. We didn’t want to bet on a single proprietary platform. Allowing access from as many places and computing devices as possible motivated our choice of the web platform and developing with HTML5.

HTML5 LogoSo should you develop in HTML5 or native? Well, it depends.

HTML5 in and of itself doesn’t necessarily mean much. HTML5 is a standard still under development. It’s a set of specifications at various levels of development and support. Strictly speaking, a web page can be made HTML5 by changing one line in it. So writing an HTML5 app is mainly writing against parts of a new set of specifications that form the more modern parts of the web platform.

When building for mobile, the good news is that most mobile browsers are fairly recent and actively developed. When building on the web platform, the bad news is you still have to support old browsers. IE6, one of the worst browsers still in use, is almost dead. But IE8 isn’t much better. Thankfully, obsolescence happens faster on mobile (more on that later). In MommaZoo, we’ve mitigated some of the cost of supporting inadequate browsers by using the Chrome Frame for older versions of IE. We also don’t support the oldest Android versions.

A common question is whether HTML5 is mature enough. In most cases, you just need to know about the support across browsers to know. There are many resources to help you.

But more than anything else, Javascript performance is what made HTML5 possible (before version 5, HTML specifications limited themselves to markup while it now includes Javascript APIs). Browsers are in fierce competition to be the fastest Javascript engine on the planet and a lot of developer resources are spent on it. It’s what made most rich web applications you’re using today possible.

Overall, the platform is mature enough. Most Javascript runtimes are really good. A reasonable subset of the HTML5 specifications are finalized, well-supported and well-tested. The community is large and active. But as for any platform, it doesn’t mean there aren’t sharp corners when you get close to the edges. Just try to identify those early, assess whether you can stay away or how much bleeding it could cause.

For MommaZoo, by targeting the web platform, our cost of development can be kept reasonable while still maintaining a very wide reach. Our parent demographics requires it. MommaZoo hasn’t been developed without pains however, and I’ll get into those difficulties and how to alleviate them in the next post.

Categories: Uncategorized
Follow

Get every new post delivered to your Inbox.

Join 34 other followers