search

Schroedingers-Hat / jsphys

Libraries for physics simulation on javascript canvas
GNU Affero General Public License v3.0
11 stars 1 forks source link

UI changes #124

Open Schroedingers-Hat opened 12 years ago

Schroedingers-Hat commented 12 years ago

Central place to discuss improving the interface.

One thought I had was to replace the click handling with the facility to select objects (think RTS style).

A menu could then be available which would include teleporting, measuring the distance/time/etc to another object (in rest frame or in object's frame), change the object's options, and possibly some other things I haven't thought of.

This would solve some of the issues with rulers not being very intuitive (and thus me not having a good idea of how to implement them well).

In addition to this it would make teleporting discoverable/make sense.

Another thought would be a separate ruler overlay. Basically functioning the same as a ruler measuring on the physical display (or as you'd use one on a map), but with a self-calibrating scale. This could probably be done outside the canvas, and may be less resource intensive that way.

This seems relevant: http://css3please.com/ seems to be a sub-set of the functionality of that post-it. Not supported in opera<11, ie<9. Don't really want it breaking IE8 (although it's probably significantly broken atm anyway) Could either make it optional feature, or do something in the canvas.

capnrefsmmat commented 12 years ago

Hm. Wouldn't that require pausing before clicking? A lot of demos move too fast for a user to click, select the correct menu item, and view the results. Though if we could pre-create rulers in the demo, we could cover the useful cases, and let users pause if they want to alter the demo settings.

Schroedingers-Hat commented 12 years ago

I was more thinking for exploration and/or create your own experiment type things. If we include audio we'll also be able/want to make longer or slower moving demos. Could even have a section after the next button is highlighted where the yammering about less important-but-still-related stuff (interesting history, other details) happens. While this is happening the student could be encouraged to rewind time and try some related things.

Also anything demo driven could/should be pre-programmed.

capnrefsmmat commented 12 years ago

I also really, really like the idea of having narration audio that plays automatically. With a polished demo system, it'd be a really effective teaching tool.

Let's save the RTS-style object selection for a while; once we implement all the demo system features we have planned now, we can see what the best strategy is.

Schroedingers-Hat commented 12 years ago

Your skill-set and knowledge of surrounding code is more suited to making audio load and be ready to play. If you can make the demo loader automatically ready some files, and perhaps make some kind of queue, or some way of getting it to call a function it's given when it finishes playing (accessable from scene, perhaps?) I'll fix up fourEvent to be a little bit more causality-robust. I'm imagining something like: {'object': 'fourEvent', x: .... 'options':{'caption': 'blah', 'audio':'foo'} } then when it loads the demo it'll get foo ready to play (along with any other audio in other fourEvents), which I can trigger from fourEvent() itself.