Wow @Jay, that's a bit of a lecture there ;) @Ryan, we've tried and tested the iframe approach you suggested and I've got my answer:
Yup, you're right. The reason is speed, loading an iframe causes the main ajax request to take about 30% longer in averege which is a lot (even if it's only 100-200ms) so I gotta shelf the idea, at least until I can get the speed facebook has achieved. Good lesson anyway! Cheers all On Jul 12, 10:23 am, André Fiedler <[email protected]> wrote: > @Jay That´s great! That´s the way i´m doing this, too. ;o) > > 2010/7/12 Jay <[email protected]> > > > I find my most creative work comes from being restricted from doing > > something the way I'd initially want to do it. When being forced to > > work within confined limits, you can often come up with an elegant > > solution that's cooler and more usable than existing implementations. > > Instead of having wacky IFrames and stuff, what if you would use a > > slightly-less-standard paradigm for user feedback? Start with the > > basics. To preach to the choir, I almost ALWAYS set the cursor > > property if I'm doing time-consuming requests, as Mr. Newton > > suggested. I'm not sure why, but even something as subtle as that > > seems to have a huge effect on the user of the site. If you think you > > need more feedback than that, what if you did a "Loading..." message > > in the style of GMail? Something like that could integrate beautifully > > with the design of your site, and would give your app a really novel > > feel. > > > But, of course, it always depends what you're going for. If you really > > really really need to simulate that browser behavior, IFrames are the > > only way to go. However, I imagine that the extra requests to IFrames > > + extra load on your server + JavaScript overhead would make your AJAX > > site load just as slowly (if not more so) than a traditional site, > > which seems to defeat the purpose of AJAX in the first place > > (especially when you consider its usability concerns for the outskirts > > of the internet world -- screen readers, old web browsers, javascript- > > blocking firewalls and paranoid javascript disablers. Coincidentally, > > the people I find I need to emulate "traditional" methods for to avoid > > confusing them are the same people that -- of course -- use screen > > readers, old web browsers, and the like. At which point, I make sure > > the site gracefully degrades, and kill two birds with one stone. > > > On Jul 10, 4:28 pm, Ryan Florence <[email protected]> wrote: > > > :D > > > > Momentary lapse of reason... > > > > Sent from my iPhone > > > > On Jul 10, 2010, at 10:35 AM, jiggliemon <[email protected]> wrote: > > > > > @Ryan > > > > > OMG <--- meant to be rude. > > > > > -Chase > > > > > On Jul 9, 9:37 pm, Aaron Newton <[email protected]> wrote: > > > >> <facepalm> > > > > >> On Fri, Jul 9, 2010 at 2:50 PM, Ryan Florence <[email protected]> > > wrote: > > > > >>>> For now I'm thinking about a class, similar to Request.HTML that > > gets > > > >>>> stuff into an iframe, loads it, then returns the content into > > > >>>> onSuccess and removes the iFrame? Not AJAX, but might work - would > > > >>>> that make sense? > > > > >>> If I was forced to code it I would have the request be a normal > > request > > > >>> and then add onRequest and onComplete events. > > > > >>> onRequest I'd create an iframe element with a src pointing to a file, > > that, > > > >>> on the server side (assuming php) is just a big long sleep(), like > > > >>> sleep(10000000000). That should force the browser into a "loading > > state". > > > > >>> And then onComplete destroy the iframe element. > > > > >>> I love to beat dead horses. A simple indicator by the link or over > > the > > > >>> content that's updating is enough ...
