Algebra Rizing
in [Lisp]
|
From: His kennyness on 30 Jun 2010 12:35 On 06/30/2010 11:03 AM, John G Harris wrote: > On Wed, 30 Jun 2010 at 09:35:52, in comp.lang.javascript, His kennyness > wrote: >> On 06/29/2010 11:41 PM, RobG wrote: >>> On Jun 29, 8:43 pm, Kenneth Tilton<kentil...(a)gmail.com> wrote: >>>> Now you can ask for hints (and a bunch more is fixed): >>>> >>>> http://teamalgebra.com/ >>> >>> Very slow to load, over 20 seconds. >> >> I get 1-2s, ie, too fast to notice. > <snip> > > Your soa.js is 1,077,248 bytes long. To get a 2s download time you need > an 8+Mbit/s connection transferring at full speed. You should assume > that many of your broadband customers are getting only 2Mb/s. I have a standard cable-based broadband connection. teamalgebra.com came up in (I lied) four seconds. This is running in a virtual machine that has never surfed the web beofre, so nothing was cached. cnn.com came up in twelve seconds. case still closed. > > Your sure.png is over 118 kB. It can be reduced to 17 kB without > degradation by making it a GIF file with 32 colours. > Forest. Trees. Please note order. kt
From: Richard Cornford on 30 Jun 2010 13:16 On Jun 30, 2:35 pm, His kennyness wrote: > On 06/29/2010 11:41 PM, RobG wrote: <snip> >> The delete key does nothing. > > Yeah, and that is going to be tricky in a wysiwyg math editor, But for some reason not that tricky in browser-based wysiwig HTML editors. > but I used to handle that so ... eventually. The backstory is > that in the past I spent hundreds and hundreds of hours > implementing drag-select, cut-and-paste, etc etc and I am pretty > sure that that was a waste of time for an Algebra basics tutorial. > Kids just will not use cut/paste for -3x-2>13. yet the > development cost is extraordinary. Hell, i am not even worried > about letting them click to position the cursor. > > The moral is: without an unlimited budget (meaning, "always") > do not implement cool feature X until a good number of people > (other than JS library haters) ask for it. <snip> That would be a conclusion that suggest you haven't understood what you have done. The standard HTML input field had support for delete, navigation (of characters, words, etc.) by keyboard, home, end, insert/ overwrite, cursor positioning by mouse, drag selection, copy, paste, etc., etc. And usually using OS native idioms familiar to the user form their experience with other software in that environment. All of this built-in, handled by the browser and available at precisely zero effort to the javascript programmer. (And that is without even considering features such as - contentEditable - and the like for non- form control elements.) If you are working in a browser and you don't have these facilities then that is not because you haven't bothered to make the effort to put them in, it is because you made some effort to design them out. And not appreciating that suggest you designed them about without realising that you were doing so, which is probably true as you were determined to disregard the warnings you were given about qooxdoo when you first proposed using it. And it is the decision (your decision, despite advice to the contrary) to use qooxdoo is the point where you designed a whole host of useful/desirable features out of your product. The qooxdoo approach, of attempting to do away with the browser's HTML, and its accompanying layout and presentation facilities in favour of a fully scripted alternative is initially appealing because it allows a (superficial) level of direct control over the presentation that does not appear to be available otherwise. Many people have tried it, and given up when they realised the depth of the problems they were creating for themselves. These problems include, but are fare from limited to, recreating all of the (familiar, to the user) keyboard interaction features that the browser would have been providing for free. These things are difficult to script, especially when you consider their full range, the differences in styles between OS, alternative input methods (e.g. Tablet PC's handwriting input methods), alternative keyboard layouts and accessibility generally. So the creators of libraries that attempt to provide a fully scripted user interface don't tend to provide these things, because they have avoided the HTML provided facilities and, either out of ignorance of their existence, the extent of their existence, the inability to implement them or the realisation that implementing them will bloat and slow their product to the point where it will be seen as non- viable, they have done little (or nothing) to script these things back into their libraries. And this is qooxdoo, there appears to be much breadth in its set of UI widgets but there is very little depth to them; they are nowhere near to being finished (in the sense of providing equivalent facilities to those that the browser would have provided, if asked to) and the amount of additional code that will be needed to finish them is not going to help a framework that is already bulky and slow. You will, of course, assert that you don't care. But in the end the reactions to qooxdoo expressed to you in the past are really not just the knee-jerk reactions of "JS library haters", but are instead, at least in part, a reaction to an understanding of what qooxdoo is doing, how far short it is currently falling of achieving what it is attempting, and that any choice to use it will have considerable negative consequences (not least in terms of the facilities provided by any possible user interface). Richard.
From: Gildas on 30 Jun 2010 14:35 On 29 juin, 12:43, Kenneth Tilton <kentil...(a)gmail.com> wrote: > Now you can ask for hints (and a bunch more is fixed): > > http://teamalgebra.com/ > Hi, Do you really need to send to your server a XHR each time I hit a key or click in the input control ?
From: His kennyness on 1 Jul 2010 01:19 On 06/30/2010 02:35 PM, Gildas wrote: > On 29 juin, 12:43, Kenneth Tilton<kentil...(a)gmail.com> wrote: >> Now you can ask for hints (and a bunch more is fixed): >> >> http://teamalgebra.com/ >> > > Hi, > > Do you really need to send to your server a XHR each time I hit a key > or click in the input control ? > Have you seen the code behind the math editor? Obviously a port to JS would be worthwhile when there are no other problems to solve, or if the round-trip itself turns out to be a show-stopper. But what I am sure you have not considered is the typing speed of a student doing Algebra. I am also sure that you believe "texting" from cell phones will never catch on because it is so hard typing in the messages. Keep up the good work. kt <what a bunch of losers>
From: His kennyness on 1 Jul 2010 01:26
On 06/30/2010 09:25 PM, RobG wrote: > On Jun 30, 11:35 pm, His kennyness<kentil...(a)gmail.com> wrote: >> On 06/29/2010 11:41 PM, RobG wrote: >> >>> On Jun 29, 8:43 pm, Kenneth Tilton<kentil...(a)gmail.com> wrote: >>>> Now you can ask for hints (and a bunch more is fixed): >> >>>> http://teamalgebra.com/ >> >>> Very slow to load, over 20 seconds. >> >> I get 1-2s, ie, too fast to notice. > > It loads in 5 to 10 seconds sometimes, but that is over a very fast > connection. ha-ha, awesome, I am up to 4, you are down to 5-10. Another couple of messages and we may pass each other. I feel a word problem coming on... one flamer leaves from 2s at 10am, another leaves from 30s six hours earlier... kt |