6 ms·

This app seems to be a blend of native UIKit development and jQuery Mobile. The navigation on the left-hand side is native and really fluid, but on the right-ha

by jannes 15y ago

This app seems to be a blend of native UIKit development and jQuery Mobile. The navigation on the left-hand side is native and really fluid, but on the right-hand side (where the videos and subtitles are) is a UIWebView with jQuery-Mobile-powered pages. That's why the scrolling performance of the subtitles is so shitty (compared to native scrolling) and why the "share" and "download" buttons don't really look native. But an average user wouldn't notice these things, so I guess they're not important. I just don't understand why the developers didn't do everything natively. What are the advantages of using - in my mind - inferior technology like jQuery Mobile in an app that's completely custom-built anyway? It can't be that much more work to do the whole interface with UIKit. Other than that I think it's a really good app (and great content, too). So, congratulations to the developers and Sal!

clintjhill 15y ago
I agree with the point of your question, but I do know that in some cases it's a matter of codebase count. Which is to ask would it be better to have 1 codebase that serves as your website and native views? Or is it better to have X number of codebases for your views based on the number of platforms you'd like to be on? Especially when in all cases the views should be the same regardless of platform/native. Sometimes native is forgone to provide more centralization of views. It's not always good to custom build for every platform when you want consistency in your UX across all platforms. It all depends. EDIT: Grammar.
- jannes 15y ago
  I see where you are coming from. And I agree that it's a trade-off. But I think my point is, that from a usability point of view you simply have no other choice than having X codebases, one for each platform you want to be on, if you are not willing to compromise on usability. I don't know of anyone who tried themselves at the magical "write once, run anywhere" and delivered a consistently great user experience. Of course, it would be hyperbolic to say that the Khan Academy app has some huge usability flaws. It hasn't. But I'm mostly thinking about another example here: Facebook. They're a billion dollar web company and even they managed to majorly fuck their mobile apps up in terms of responsibility and general snappiness. They tried "write once, run anywhere" and failed. There was an article about Facebook's mobile technology on ReadWriteWeb some time ago: http://www.readwriteweb.com/mobile/2011/09/how-facebook-mobile-was-design.php http://www.readwriteweb.com/mobile/2011/09/how-facebook-mobi... (I hope this information isn't outdated already) HN discussion is here: http://news.ycombinator.com/item?id=3397872 http://news.ycombinator.com/item?id=3397872 I think empirical evidence shows that this is the wrong approach if you want to deliver a good user experience.
- adamjernst 15y ago
  I'm the iOS developer on the Khan app, and not having to maintain a codebase for multiple platforms is one of the main reasons why we went with jQuery Mobile. Khan Academy has a lot of custom logic (badges being awarded, points being accrued, and so on) and duplicating that across platforms would be a nightmare.
Pent 15y ago
The app feels much like the WebOS version, so I will guess that they borrowed some of the WebOS code and used it in the iPad version to save time.
- spicyj 15y ago
  Actually, the WebOS version (which wasn't developed in-house) shares no code with the iPad one.
angrycoder 15y ago
> It can't be that much more work to do the whole interface with UIKit. It really does take that much more time. Just to use a simple example of displaying a list of data. An experienced web developer can take a list of data from a database or web service, loop through it, and spit out a decent looking page in 10-15 minutes. Maybe take an 15-30 minutes of tweaking and styling to make it really look professional. Now, doing the same thing on iOS, you use what is called a UITableView. There is no type of magic data binding included, so you have to wire the whole thing up by hand. A bit more extra work but nothing too terrible so far. Now, tableviews are great if you only need to display text in one of 4 predefined ways, but that usually ends up not being the case. You end up having to make your own UITableCells to get things laid out just the way you want. So you make a cell and start loading it up with different label fields, one for each differently styled piece of text you want, image controls, etc etc. Now, if you are doing this the 'right' way, each of these cells should have their own controller because by now the method that is providing the cells to the UITableView has a ton of logic in it and is acting as the controller for your custom cell. But, you have to maintain this list of controllers seperately inside your UITableViewController, further down the rabbit hole you go. You think you are all done, but depending on how fancy your cells are and how long your list is, you notice the scrolling is jerky, not smooth, not very 'iPhoneish'. So you read some more and figure out the only way to get really smooth scrolling when dealing with complex cells is to manually draw them yourself and not rely on a collection of controls contained inside the cell. So there you sit, drawing out your individual cells with pen-style graphics methods and blitting text and images like you are a video game developer. Most of the nice interactions you think of as being native, aren't. They are something that a developer had to do by hand. Even something like not having the keyboard cover up a text field has to be done manually. I'm not saying it isn't worth the time to do a full native app, but it does require a lot of time, UIKit gives you very little for free.
- reidmain 15y ago
  You realize that is just a matter of experience? Using the frameworks I've developed I can have a iOS app hit a web service and display a list of data in 30 minutes max. I could write three paragraphs on all the "complex" stuff I'd have to do using JavaScript and CSS and make it sound a lot worst than UIKit just because I am inexperienced. UIKit gives you so much for free. It is why so many iPhone apps look "iPhoneish" because if you follow the good programming practices you get them for free.
adamjernst 15y ago
Hi—I'm Adam Ernst, the iOS-side developer of the Khan app. Your assessment of the app's hybrid nature, and the performance problems that result, is correct. We know that the performance is subpar, and it wouldn't have been much more work for me to do the rest in native code. Khan Academy recently hired John Resig, with whom I had the pleasure of working on this app. John is the inventor of jQuery and a core developer on jQuery Mobile. He's amazingly talented and has really pushed the Javascript world ahead. It's no surprise that John is eager to improve jQuery Mobile, and his work at Khan Academy is a great real-world project on which to use it. John tackled the jQuery Mobile side of the project, and I filled in native code for the parts (like the navigation) that would have been far too slow in Javascript. I'm sure John will continue optimizing jQuery Mobile to improve its performance. So just stay tuned; the jQuery Mobile project has been moving incredibly fast. And thanks, John, for the opportunity to work with you!

by jannes 15y ago

clintjhill 15y ago

I agree with the point of your question, but I do know that in some cases it's a matter of codebase count. Which is to ask would it be better to have 1 codebase that serves as your website and native views? Or is it better to have X number of codebases for your views based on the number of platforms you'd like to be on? Especially when in all cases the views should be the same regardless of platform/native. Sometimes native is forgone to provide more centralization of views. It's not always good to custom build for every platform when you want consistency in your UX across all platforms. It all depends. EDIT: Grammar.

jannes 15y ago
I see where you are coming from. And I agree that it's a trade-off. But I think my point is, that from a usability point of view you simply have no other choice than having X codebases, one for each platform you want to be on, if you are not willing to compromise on usability. I don't know of anyone who tried themselves at the magical "write once, run anywhere" and delivered a consistently great user experience. Of course, it would be hyperbolic to say that the Khan Academy app has some huge usability flaws. It hasn't. But I'm mostly thinking about another example here: Facebook. They're a billion dollar web company and even they managed to majorly fuck their mobile apps up in terms of responsibility and general snappiness. They tried "write once, run anywhere" and failed. There was an article about Facebook's mobile technology on ReadWriteWeb some time ago: http://www.readwriteweb.com/mobile/2011/09/how-facebook-mobile-was-design.php http://www.readwriteweb.com/mobile/2011/09/how-facebook-mobi... (I hope this information isn't outdated already) HN discussion is here: http://news.ycombinator.com/item?id=3397872 http://news.ycombinator.com/item?id=3397872 I think empirical evidence shows that this is the wrong approach if you want to deliver a good user experience.
adamjernst 15y ago
I'm the iOS developer on the Khan app, and not having to maintain a codebase for multiple platforms is one of the main reasons why we went with jQuery Mobile. Khan Academy has a lot of custom logic (badges being awarded, points being accrued, and so on) and duplicating that across platforms would be a nightmare.

Pent 15y ago

The app feels much like the WebOS version, so I will guess that they borrowed some of the WebOS code and used it in the iPad version to save time.

spicyj 15y ago
Actually, the WebOS version (which wasn't developed in-house) shares no code with the iPad one.

angrycoder 15y ago

> It can't be that much more work to do the whole interface with UIKit. It really does take that much more time. Just to use a simple example of displaying a list of data. An experienced web developer can take a list of data from a database or web service, loop through it, and spit out a decent looking page in 10-15 minutes. Maybe take an 15-30 minutes of tweaking and styling to make it really look professional. Now, doing the same thing on iOS, you use what is called a UITableView. There is no type of magic data binding included, so you have to wire the whole thing up by hand. A bit more extra work but nothing too terrible so far. Now, tableviews are great if you only need to display text in one of 4 predefined ways, but that usually ends up not being the case. You end up having to make your own UITableCells to get things laid out just the way you want. So you make a cell and start loading it up with different label fields, one for each differently styled piece of text you want, image controls, etc etc. Now, if you are doing this the 'right' way, each of these cells should have their own controller because by now the method that is providing the cells to the UITableView has a ton of logic in it and is acting as the controller for your custom cell. But, you have to maintain this list of controllers seperately inside your UITableViewController, further down the rabbit hole you go. You think you are all done, but depending on how fancy your cells are and how long your list is, you notice the scrolling is jerky, not smooth, not very 'iPhoneish'. So you read some more and figure out the only way to get really smooth scrolling when dealing with complex cells is to manually draw them yourself and not rely on a collection of controls contained inside the cell. So there you sit, drawing out your individual cells with pen-style graphics methods and blitting text and images like you are a video game developer. Most of the nice interactions you think of as being native, aren't. They are something that a developer had to do by hand. Even something like not having the keyboard cover up a text field has to be done manually. I'm not saying it isn't worth the time to do a full native app, but it does require a lot of time, UIKit gives you very little for free.

reidmain 15y ago
You realize that is just a matter of experience? Using the frameworks I've developed I can have a iOS app hit a web service and display a list of data in 30 minutes max. I could write three paragraphs on all the "complex" stuff I'd have to do using JavaScript and CSS and make it sound a lot worst than UIKit just because I am inexperienced. UIKit gives you so much for free. It is why so many iPhone apps look "iPhoneish" because if you follow the good programming practices you get them for free.

adamjernst 15y ago

Hi—I'm Adam Ernst, the iOS-side developer of the Khan app. Your assessment of the app's hybrid nature, and the performance problems that result, is correct. We know that the performance is subpar, and it wouldn't have been much more work for me to do the rest in native code. Khan Academy recently hired John Resig, with whom I had the pleasure of working on this app. John is the inventor of jQuery and a core developer on jQuery Mobile. He's amazingly talented and has really pushed the Javascript world ahead. It's no surprise that John is eager to improve jQuery Mobile, and his work at Khan Academy is a great real-world project on which to use it. John tackled the jQuery Mobile side of the project, and I filled in native code for the parts (like the navigation) that would have been far too slow in Javascript. I'm sure John will continue optimizing jQuery Mobile to improve its performance. So just stay tuned; the jQuery Mobile project has been moving incredibly fast. And thanks, John, for the opportunity to work with you!