I've given Daniel Kinzler (Duesentrieb) subversion write access, for work relating to an AJAX category tree extension which he has written. Daniel has been a known and respected member of the community for some time.
-- Tim Starling
Wait, does this mean Mediawiki is going to get some AJAX elements? Has that been tried outside of Google in a large scale?
On 7/26/06, Tim Starling t.starling@physics.unimelb.edu.au wrote:
I've given Daniel Kinzler (Duesentrieb) subversion write access, for work relating to an AJAX category tree extension which he has written. Daniel has been a known and respected member of the community for some time.
-- Tim Starling
Wikitech-l mailing list Wikitech-l@wikimedia.org http://mail.wikipedia.org/mailman/listinfo/wikitech-l
On 7/27/06, mboverload mboverload@gmail.com wrote:
Wait, does this mean Mediawiki is going to get some AJAX elements? Has that been tried outside of Google in a large scale?
I'm disappointed to report that our Wikipedia article doesn't actually contain a list of sites that use AJAX. But, I believe it's pretty common these days.
Steve
I meant on a thosand-hit-an-hour (minute?) website.
On 7/26/06, Steve Bennett stevage@gmail.com wrote:
On 7/27/06, mboverload mboverload@gmail.com wrote:
Wait, does this mean Mediawiki is going to get some AJAX elements? Has
that
been tried outside of Google in a large scale?
I'm disappointed to report that our Wikipedia article doesn't actually contain a list of sites that use AJAX. But, I believe it's pretty common these days.
Steve _______________________________________________ Wikitech-l mailing list Wikitech-l@wikimedia.org http://mail.wikipedia.org/mailman/listinfo/wikitech-l
mboverload wrote:
I meant on a thosand-hit-an-hour (minute?) website.
Yes.
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@solarsail.hcs.harvard.edu wrote:
mboverload wrote:
I meant on a thosand-hit-an-hour (minute?) website.
Yes.
-- Ivan Krstic krstic@solarsail.hcs.harvard.edu | GPG: 0x147C722D _______________________________________________ Wikitech-l mailing list Wikitech-l@wikimedia.org http://mail.wikipedia.org/mailman/listinfo/wikitech-l
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
mboverload 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...
But that's not AJAX...
On Wed, Jul 26, 2006 at 03:46:31PM -0700, mboverload wrote:
Wait, does this mean Mediawiki is going to get some AJAX elements? Has that been tried outside of Google in a large scale?
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.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Chad Perrin wrote:
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.
Well, about the edit preview, don't worry about. Our Parser is complicated enough that anything like that isn't happening soon.
On 7/27/06, Edward Z. Yang edwardzyang@thewritingpot.com wrote:
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.
Well, about the edit preview, don't worry about. Our Parser is complicated enough that anything like that isn't happening soon.
It already has: http://wikiwyg.org/wysi/
Erik
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Erik Moeller wrote:
It already has: http://wikiwyg.org/wysi/
I meant a "true" preview:
http://wikiwyg.org/wysi/Disadvantages
Even WikiWYG concedes that it's highly unlikely that it will get integrated into the official MediaWiki codebase.
On Wed, 2006-26-07 at 19:27 -0400, Edward Z. Yang wrote:
Even WikiWYG concedes that it's highly unlikely that it will get integrated into the official MediaWiki codebase.
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:
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@prodromou.name http://evan.prodromou.name/
On Thu, Jul 27, 2006 at 01:22:50AM +0200, Erik Moeller wrote:
On 7/27/06, Edward Z. Yang edwardzyang@thewritingpot.com wrote:
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.
Well, about the edit preview, don't worry about. Our Parser is complicated enough that anything like that isn't happening soon.
It already has: http://wikiwyg.org/wysi/
This actually works much more smoothly than most of the examples of misuse of AJAX to which I referred. At least it doesn't make each character in the entry field wait on each character being rendered before proceeding in the entry field (thank goodness). It's still kind of slow and cumbersome, but not nearly as bad as what I'd previously encountered.
On 7/27/06, Erik Moeller eloquence@gmail.com wrote:
It already has: http://wikiwyg.org/wysi/
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-3 wrote:
On 7/27/06, Edward Z. Yang edwardzyang@thewritingpot.com wrote:
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.
Well, about the edit preview, don't worry about. Our Parser is complicated enough that anything like that isn't happening soon.
It already has: http://wikiwyg.org/wysi/
For some reason that link is not working for me: I get what looks like HTML or XML source code.
HTH HAND
Erik Moeller wrote:
On 7/27/06, Edward Z. Yang edwardzyang@thewritingpot.com wrote:
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.
Well, about the edit preview, don't worry about. Our Parser is complicated enough that anything like that isn't happening soon.
It already has: http://wikiwyg.org/wysi/
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Moin,
On Thursday 27 July 2006 19:33, Timwi wrote:
Erik Moeller wrote:
On 7/27/06, Edward Z. Yang edwardzyang@thewritingpot.com wrote:
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.
Well, about the edit preview, don't worry about. Our Parser is complicated enough that anything like that isn't happening soon.
It already has: http://wikiwyg.org/wysi/
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
Is there something that prevents the AJAX (aka javascript) to override the backbutton so when the user clicks it, they get "!back to the previous" page, aka what it looked like before clicking edit?
OTOH, w/o JS and ajax etc this page wouldn't be possible at all.
best wishes,
tels
- -- Signed on Thu Jul 27 20:18:03 2006 with key 0x93B84C15. Visit my photo gallery at http://bloodgate.com/photos/ PGP key on http://bloodgate.com/tels.asc or per email.
" ...the Machholz Comet is named after the guy who really discovered it. Bob Comet." -- Zathras26 (763537) on 2005-01-01 at /.
On 7/27/06, Tels nospam-abuse@bloodgate.com wrote:
Is there something that prevents the AJAX (aka javascript) to override the backbutton so when the user clicks it, they get "!back to the previous" page, aka what it looked like before clicking edit?
OTOH, w/o JS and ajax etc this page wouldn't be possible at all.
Somehow Gmail gets the "back" functionality exactly right. No idea how it works.
Steve
On 7/27/06, Steve Bennett stevage@gmail.com wrote:
On 7/27/06, Tels nospam-abuse@bloodgate.com wrote:
Is there something that prevents the AJAX (aka javascript) to override
the
backbutton so when the user clicks it, they get "!back to the previous" page, aka what it looked like before clicking edit?
OTOH, w/o JS and ajax etc this page wouldn't be possible at all.
Somehow Gmail gets the "back" functionality exactly right. No idea how it works.
Steve
Well the sidebar and header is static, they use the email area as some sort of frame.
That's just my best guess.
On 7/27/06, mboverload mboverload@gmail.com wrote:
On 7/27/06, Steve Bennett stevage@gmail.com wrote:
On 7/27/06, Tels nospam-abuse@bloodgate.com wrote:
Is there something that prevents the AJAX (aka javascript) to override
the
backbutton so when the user clicks it, they get "!back to the
previous"
page, aka what it looked like before clicking edit?
OTOH, w/o JS and ajax etc this page wouldn't be possible at all.
Somehow Gmail gets the "back" functionality exactly right. No idea how it works.
Steve
Well the sidebar and header is static, they use the email area as some sort of frame.
That's just my best guess.
Nevermind, the sidebar and header are only static in some operations I guess.
On 7/27/06, Steve Bennett stevage@gmail.com wrote:
On 7/27/06, Tels nospam-abuse@bloodgate.com wrote:
Is there something that prevents the AJAX (aka javascript) to override
the
backbutton so when the user clicks it, they get "!back to the previous" page, aka what it looked like before clicking edit?
OTOH, w/o JS and ajax etc this page wouldn't be possible at all.
Somehow Gmail gets the "back" functionality exactly right. No idea how it works.
Google Web Toolkit has all this functionality and is the core tech that Google Calendar, GMail, etc. use. Maybe someone should do some research on how it could apply to MW? :)
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@garagegames.com wrote:
On 7/27/06, Steve Bennett stevage@gmail.com wrote:
On 7/27/06, Tels nospam-abuse@bloodgate.com wrote:
Is there something that prevents the AJAX (aka javascript) to override
the
backbutton so when the user clicks it, they get "!back to the
previous"
page, aka what it looked like before clicking edit?
OTOH, w/o JS and ajax etc this page wouldn't be possible at all.
Somehow Gmail gets the "back" functionality exactly right. No idea how
it
works.
Google Web Toolkit has all this functionality and is the core tech that Google Calendar, GMail, etc. use. Maybe someone should do some research on how it could apply to MW? :)
-- Ben Garney Torque Technologies Director GarageGames.Com, Inc. _______________________________________________ Wikitech-l mailing list Wikitech-l@wikimedia.org http://mail.wikipedia.org/mailman/listinfo/wikitech-l
On 7/28/06, Timwi timwi@gmx.net 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!").
I agree that there may be problems, but I don't necessarily agree that the edit link should always load a separate page. Editing sections or whole pages inline would arguably be a more-wiki way than loading separate pages.
On the idea raised above, live parsing may not be entirely feasible; perhaps an implementation that still does not require loading a new page, but is only triggered when the preview button is pushed?
mboverload wrote:
Wait, does this mean Mediawiki is going to get some AJAX elements? Has that been tried outside of Google in a large scale?
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
wikitech-l@lists.wikimedia.org