I would love to hear a bit about what research you've done and what your views are. I studied multimedia design, but near the end of my degree became far more interested in educational media. Any chance of sending me an email (should be public) so I can ask a few questions and pick your brains? Hoping to do more in this line of work, and would be keen to get advice on what to read, what to study, who to talk to, what best-practices to look at etc

Jason

I use haxe and I thought I'd comment here.

While you do have to learn your way around the native APIs I find I can avoid writing pretty much any "native" javascript - so you don't have to learn the intricacies of the syntax, just the environment you'll be working with - and the compile time errors will help you avoid syntax errors anyway.

As for debugging, the JS output is usually similar enough that info the debugger gives you can be translated back, but it is definitely slower. Both Chrome and Firefox are planning support for "source maps" - which map the JS output to the original language source. The haxe community is pretty keen to support the appropriate maps as soon as these features land... which should make it all a lot easier.

(Disclaimer: don't work for anyone haxe-related, just a user and a fan)

I'll vouch for haxe. I use it on any web-dev projects where I get the chance, both Client and Server side.

Basically it's a language that compiles to other languages - JS, ActionScript and PHP being among them. When using it for targeting javascript, you get some advantages:

  * Strong typing, like you're used to
  * Compile time error checking
  * Code-completion (based on the compiler, really helpful for avoiding Typos)
  * Some powerful libraries - tweening, remoting (passing objects and function calls to the server etc)

The big disadvantage is it's harder to make it work with native libraries. Not impossible, but harder. JQuery support comes built in, and there are "externs" for several of the popular libraries, and you can make your own, but it is usually more work initially. I still think it's worth it for the things mentioned above.

Other sites that might explain it better: http://www.haxejs.org/ http://haxenode.org/

This blog post from Mozilla points out that in the past the assumption was that a new addon was broken in a new version, until proven otherwise. With the new release system, Mozilla is hoping to change this so the assumption is that the old addon is compatible with the new version, until proven otherwise.

I don't know how long it will take for this change of culture to set in, but hopefully by the next cycle developers will have made sure their addons no longer mark themselves as incompatible by default.

When I uninstall an app I usually don't bother to go back in to the app store and rate it poorly. Even if it's a great app that I find really useful, I usually don't bother to look it up in the market and give it a good review.

But this data is useful for people. What could help is if the "Applications" menu made it really easy to submit a rating (and optionally a review) without having to look up the app in the store - submit it right there from the menu. And if you go to uninstall it, why not ask for a rating and a quick review then also?

I think the article's point that gestures are not as easily discoverable as menu items is a good point, and fixing this would fix many other problems.

As an example, firefox's "Options" or "Preferences" is stored in different places on different platforms, but because I know to search menus, I can find it fairly quickly, even if it was not where I expect it to be.

With gestures there's no easy way to see what action a given gesture might execute without doing the guesture. And you're sometimes afraid to try because not every app has an undo feature. What if different platforms standardised on a way to show which gestures you're about to execute. So if you long press on an item, it could display some gesture tips on the screen - a circle of labels could demonstrate that dragging right means "open", dragging left means "back", dragging up is "share" and dragging down is something else. This way, even if the gestures were different on different platforms or different apps, the method for discovering them could be standardised.

I work in a private Australian high school, and our principal has recently decided that he wants every student to have an ipad.

We had a sales rep from Apple come out, and asked him this, if they can be locked down. The answer was basically no, what you get on a consumer ipad is what the kids will have on their school one. Apple's answer to students playing games on them: "that's a social problem, and it needs a social solution". A commenter above mentioned that even with books you can draw in the margins, and boring lessons will remain boring lessons, and distracted kids will still be distracted kids.

So I think the iPad will give the opportunity for really good teachers to make their lessons more interesting than Angry Birds or whatever game people are playing now. (Heck, why not make an angry birds clone that ties into a very basic maths lesson about quadratic equations?) But for teachers who don't know how to make their content interesting, it'll be easier than ever for the kids to find a wealth of distracting activities to keep them occupied.

I hope any schools that go ahead with an ipad-for-every-student program have some good quality teachers, my school included...

I'm using Indefero (http://indefero.net/). It's PHP based, and made to be similar to google code, so very bare bones - but I find that is less intimidating to non-developers. (BTW, the website emphasises prices and planning and stuff, but it is open source - the prices are for their hosted service.)

-jason

It might not cover all Unicode characters, but you can get a lot of useful characters using the Compose key. I first heard about it from this blog post, which explains it well.

You can set it up in KDE -> System Settings -> Input Devices -> Keyboard -> Advanced -> Compose Key.

Of course, that's just a few handy characters, not support for all of unicode. So your point still stands.

Couldn't agree more. I was a long time Illustrator user when I had to create some simple vector graphics on a work computer without Illustrator installed, and so downloaded and installed Inkscape.

I was impressed, so much so that it's my main Vector Graphics editor now. I have a few moments where I miss Illustrator, but far more moments where I'm impressed with Inkscape. I don't use it because I'm too cheap to afford Illustrator, or for ideological open source reasons. I use it because for me, it's the better tool for the job.

Well worth checking out for anyone who needs to do some vector graphics...

Can't agree more on reading The Design of Everyday Things. I'll have to take a look at The Non Designer's Design Book.

To anyone interested in interface design, I'd also recommend one by the same author, Emotional Design: Why We Love (or Hate) Everyday Things, or the book mentioned in the article, Understanding Comics: The Invisible Art

Those three books were very easy reads and probably taught me more about interface design than the my 3 years at uni. I thoroughly recommend them.

Long ago, in a galaxy far away, I helped my dad build a Heathkit stereo amp and an FM tuner. I was six or seven, and it was great! My dad knew tons about mechanical stuff and explosives, but not much about electronics beyond house and car wiring, so we got to learn a new area together. My mom was totally cool with the burn marks on the table and the rug from stray solder blobs. The gear worked the first time we turned it on, and it was still in use when I left home for college. Thanks for some wonderful memories, Heathkit!

Copyright on scientific articles is the most evil of all, in my opinion as a researcher. I, and most other fellow scientists don't get paid by the publisher for our works. In fact, the salary of a scientist in general is meager. But we find pleasure in what we do, and in sharing our science with humankind. What we do is intended for everybody, and not to perpetually keep money flowing into the coffins of the Elseviers, the IOPs, Wileys of this world. I am astonished sometimes, to see that a lot of fundamental articles, published decades ago (in the 60's, or even earlier) is still not freely accessible by the public. I can't help but think "what douchebags, profiting like leeches from the work of scientists, many now defunct, whereas the work was intended for the whole world".

Sure. Any version of Linux that is old enough to have passed into the public domain would by definition fall outside the GPL or whatever licensing scheme it was under. Newer versions, being published later, would still be protected under standard copyright laws.

Here's a brilliant idea: use dynamic scalable/reflowing UI layouts. You know, like we've been doing on the desktop and the Web for the last 15 years or so?

In fact, I'm so generous I won't even patent that idea. Feel free to use (but also check with Nokia, just in case).