Optimizing javascript UIs is an interesting and underexplored problem. This paper at UIST 2007 demonstrated that it was possible to do a really good job of it, _if_ one invested enough effort. > *Enabling Efficient Orienteering Behavior in Webmail Clients* > Stefan Nusser, Julian Cerruti, Eric Wilcox, Steve Cousins, Jerald Schoudt > /IBM Almaden Research/ Unfortunately we don't have enough manpower to invest that effort. But it would be great if someone felt like taking it on....
David Huynh wrote: > Hi Ivan, > > Thank you for your suggestion! We have actually entertained that option > before, and considered DOM optimization to be a good thing in general. > We will eventually get to it... This is not a trivial task. The > challenge is to introduce the optimizations while still keeping the code > simple enough. > > As for requiring Enter in the text search facet, that's quite easy. :-) > > David > > Ivan Zhidov wrote: > >> I have a suggestion on how to deal with large data sets which take >> awhile to load but I don't know if it is feasible in the current >> implementation. >> >> As I understand a lot of the delay dealing with loading large data >> sets comes from having to render DOM elements. What I'm suggesting is >> lazy DOM creation. >> As a choice DOM elements should be rendered only if they'd be visible >> within the context of the current search. This would not be universal >> but optional behavior. >> One can define a number of data elements that should be rendered upon >> start up. The rest should be rendered only if they would be visible >> given current app context ( e.g. search keyword, facet selection) Also >> another suggestion is to have optionally turn off immediate rendering >> upon load of a certain data set. For example if I'm loading 3 data >> sets and I only want to display 2 out 3 immediately, this could be >> accomplished with the current showAll=false and set size. >> >> Another thing that would be helpful is to introduce a delay between >> search field entry and rendering as optional parameter to where the >> search function doesn't kick in until a certain window has passed >> since the last user entry because on large data sets when a user >> starts typing the keyword the 'found' subset is rapidly shrinking from >> a lrage to smaller subset as the user is typing so the delay would be >> more user friendly. Another option would be to turn the dynamic search >> off and let the user press 'enter' to proceed with the search. >> >> I find dynamic search behavior very impressive but from what I've >> noticed the casual web users tend to expect to hit enter key when they >> are done entering as they are not used to dynamic search >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> General mailing list >> [email protected] >> http://simile.mit.edu/mailman/listinfo/general >> >> > > _______________________________________________ > General mailing list > [email protected] > http://simile.mit.edu/mailman/listinfo/general > _______________________________________________ General mailing list [email protected] http://simile.mit.edu/mailman/listinfo/general
