I meant on a thosand-hit-an-hour (minute?) website. On 7/26/06, Steve Bennett <stevage(a)gmail.com> wrote:

Ok, well I'm excited to see what he can bring to the table. I think the edit box could use some work IMO... On 7/26/06, Ivan Krstic <krstic(a)solarsail.hcs.harvard.edu> wrote:

On Wed, Jul 26, 2006 at 03:46:31PM -0700, mboverload wrote: A great many, actually. My biggest gripe with many AJAX implementations is the supid character-by-character preview rendering that is done on many smaller sites, such as blogs. On a slow system, this means that in the time it would take me to type a 750 word essay the friggin' thing might have only completed showing me a sentence and a half. Whatever AJAX enhancements are made, let's try to stay clear of stuff that changes the appearance of the page with every single keystroke. Please. -- CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ] unix virus: If you're using a unixlike OS, please forward this to 20 others and erase your system partition.

On 7/27/06, Edward Z. Yang <edwardzyang(a)thewritingpot.com> wrote: It already has: http://wikiwyg.org/wysi/ Erik

On Wed, 2006-26-07 at 19:27 -0400, Edward Z. Yang wrote: I think there's a grave naming problem going on, since there's a very good Javascript toolkit called wikiwyg that is slowly on its way into MediaWiki in some capacity: http://www.wikiwyg.net/ I think its the biggest hope for getting wysiwyg editing features into MediaWiki. I think there are very high acceptance criteria for having it installed on Wikimedia -- being bug-compatible with every crazy hack that people do with Wikitext -- but I don't think they're insuperable. I'm not sure what the probability of that Ajax-y MW code migrating to the core is, though. ~Evan ________________________________________________________________________ Evan Prodromou <evan(a)prodromou.name> http://evan.prodromou.name/

On 7/27/06, Erik Moeller <eloquence(a)gmail.com> wrote: OMFGWTFBBQ that is awesome! I love: - it immediately highlights in the output where you are in your input. That's one of the slowest parts of non-wysiwyg editing - trying to match up the output and input. (it could be even more awesome if you could click on the output and be taken to the corresponding part of the input) - you only see a small part of the output, but it scrolls up and down as you scroll up and down the input. I drool. Steve

Erik Moeller wrote: Can I comment on this? It has one problem that peeves me on other AJAX sites too... :-) The problem is when people overuse AJAX when it is inappropriate. In this case, clicking an "edit" link is one such case. It completely changes the appearance of the screen, therefore the user understands it as a separate page, therefore the user expects to be able to go back by clicking the browser's "back" button. Using AJAX to change the page removes this functionality and makes it a frustrating experience ("It won't let me go back! Help!"). Timwi

On 7/27/06, Tels <nospam-abuse(a)bloodgate.com> wrote: Somehow Gmail gets the "back" functionality exactly right. No idea how it works. Steve

On 7/27/06, mboverload <mboverload(a)gmail.com> wrote: Nevermind, the sidebar and header are only static in some operations I guess.

We need Wikipedia to be as fast in changing pages as Google. Shit, maybe they might even donate some engineer time to help implement it. - mboverload On 7/27/06, Ben Garney <beng(a)garagegames.com> wrote:

mboverload wrote: MediaWiki has already got some AJAX elements. We've had a server-side distribution framework since March, and an initial application to go with it: a search as you type feature. That particular feature is probably impractical on Wikipedia due to the server load, but there are plenty of other features which can be implemented which can be done quite efficiently. For example, I imagine the responses for the category browser could be cached by squid, and purged in the same way that category pages are currently purged. From the server point of view, it's a lightweight way to deliver category data, compared to full category pages. Some Wikipedia users have been using AJAX for quite some time, via their user javascript. I'd like to see those features available to everyone, if server load allows. And it's easier to optimise for server load if the development effort on the server side and the client side is integrated. There are of course other advantages to integration: client-side developers are prone to spending huge amounts of time trying to extract data from the machine-unfriendly UI, when an XML or JSON server-side API could be trivially implemented. I know there are a lot of usability and accessibility concerns relating to AJAX, but hopefully, by collaborating with users, we can avoid the worst of them. This isn't some ecommerce shopping basket rush job, thrown together overnight by a couple of overpaid consultants. Wikipedia has always aimed to be accessible from the widest variety of systems. -- Tim Starling