|
3 years ago ::
Oct 13, 2010 - 4:59PM
#81
|
|
|
Here are my thoughts on the compendium.
I am a big fan of the streamlined, slimmed-down look. However, I will admit that I tried for a little bit to set up a filter before searching for anything. I have suggested that there be something added to the filters area saying that filtering options appear once a search has been performed.
Why not hide the filters until there is a use case for them? Most good user interfaces are context sensitive and only expose the controls necessary for the current task. Looking closer at this I think something need to happen to the filters if one searches again (the filters stay put but are not actually applied although they look like they are).
This email is to confirm that we have stopped automatic billing for your subscription.
Your subscription will continue to be active until the expiration date listed below.
|
|
|
|
3 years ago ::
Oct 13, 2010 - 5:02PM
#82
|
Date Joined:
Sep 28, 2006
|
Here are my thoughts on the compendium.
I am a big fan of the streamlined, slimmed-down look. However, I will admit that I tried for a little bit to set up a filter before searching for anything. I have suggested that there be something added to the filters area saying that filtering options appear once a search has been performed.
Why not hide the filters until there is a use case for them? Most good user interfaces are context sensitive and only expose the controls necessary for the current task. Looking closer at this I think something need to happen to the filters if one searches again (the filters stay put but are not actually applied although they look like they are).
I suspect that my problem was due to my use of the compendium previously, where the filters were already there.
|
|
|
|
3 years ago ::
Oct 13, 2010 - 5:15PM
#83
|
|
|
Here are my thoughts on the compendium.
I am a big fan of the streamlined, slimmed-down look. However, I will admit that I tried for a little bit to set up a filter before searching for anything. I have suggested that there be something added to the filters area saying that filtering options appear once a search has been performed.
Why not hide the filters until there is a use case for them? Most good user interfaces are context sensitive and only expose the controls necessary for the current task. Looking closer at this I think something need to happen to the filters if one searches again (the filters stay put but are not actually applied although they look like they are).
I'll support Mudbunny's stance on this, at least partially - I think there's a case for presenting filtering options up front, before executing a search, so they can act as field limiters rather than result filters. It would enhance my use of the compendium, if nothing else, and that's what's important. 
|
|
|
|
3 years ago ::
Oct 13, 2010 - 5:19PM
#84
|
Date Joined:
Sep 28, 2006
|
Here are my thoughts on the compendium.
I am a big fan of the streamlined, slimmed-down look. However, I will admit that I tried for a little bit to set up a filter before searching for anything. I have suggested that there be something added to the filters area saying that filtering options appear once a search has been performed.
Why not hide the filters until there is a use case for them? Most good user interfaces are context sensitive and only expose the controls necessary for the current task. Looking closer at this I think something need to happen to the filters if one searches again (the filters stay put but are not actually applied although they look like they are).
I'll support Mudbunny's stance on this, at least partially - I think there's a case for presenting filtering options up front, before executing a search, so they can act as field limiters rather than result filters. It would enhance my use of the compendium, if nothing else, and that's what's important.
I think either presenting the options up front, or having an indication that they will ony appear when the search is completed. I know that I refreshed the window a couple of times at first, because the large empty space made me think that something on the page had not completely loaded. Maybe it was my NoScript extention for Firefox that was interfereing? Perhaps my work firewall??
|
|
|
|
3 years ago ::
Oct 13, 2010 - 5:24PM
#85
|
|
|
Here are my thoughts on the compendium.
I am a big fan of the streamlined, slimmed-down look. However, I will admit that I tried for a little bit to set up a filter before searching for anything. I have suggested that there be something added to the filters area saying that filtering options appear once a search has been performed.
Why not hide the filters until there is a use case for them? Most good user interfaces are context sensitive and only expose the controls necessary for the current task. Looking closer at this I think something need to happen to the filters if one searches again (the filters stay put but are not actually applied although they look like they are).
I'll support Mudbunny's stance on this, at least partially - I think there's a case for presenting filtering options up front, before executing a search, so they can act as field limiters rather than result filters. It would enhance my use of the compendium, if nothing else, and that's what's important.
I think either presenting the options up front, or having an indication that they will ony appear when the search is completed. I know that I refreshed the window a couple of times at first, because the large empty space made me think that something on the page had not completely loaded. Maybe it was my NoScript extention for Firefox that was interfereing? Perhaps my work firewall??
As far as I know, it loads empty (I mentioned that in a previous post here - it looks broken when you first load it). I would figure the search box strongly and if there are no results yet, show no large expanses of blank white or anything - that is, don't show results or results space until after a search has been executed.
Again, I'm coming at this from my library experience - the online catalogs and bibliographic databases I use (which is what the Compendium is) do not display results - or the absence thereof - until a user has executed a search (and in most cases, the user has the option to set certain limiters on that search before doing so - e.g., entering your search terms and indicating that you only wish to search in the Title or Author fields in a library catalog).
If it were up to me, the huge expanse of white would be absent when the compendium first loaded, and the filters area would offer filter settings applicable to all searches. Only after a search was completed would the results list or its container appear.
|
|
|
|
3 years ago ::
Oct 13, 2010 - 5:27PM
#86
|
Date Joined:
Sep 28, 2006
|
I wonder, and keep in mind this is pure speculation based on a sum total of 0 experience in coding search engines or optimizing them, if the reason that the filters don't appear until after the search has been done is part of the dramatic increase in the speed of the Compendium?
|
|
|
|
3 years ago ::
Oct 13, 2010 - 5:31PM
#87
|
|
|
I wonder, and keep in mind this is pure speculation based on a sum total of 0 experience in coding search engines or optimizing them, if the reason that the filters don't appear until after the search has been done is part of the dramatic increase in the speed of the Compendium?
They are not part of the speedup. When all you see is the blank square the browser has already downloaded the data from the server, done it's magick and stuff. All that is missing is a JavaScript event that will toggle visibility which is computationally cheap. It seems to me from glancing at the HTML and JavaScript that almost all speedup must have been done on the server and data transfer part of things.
This email is to confirm that we have stopped automatic billing for your subscription.
Your subscription will continue to be active until the expiration date listed below.
|
|
|
|
3 years ago ::
Oct 13, 2010 - 5:32PM
#88
|
|
|
Couldn't tell you, but I doubt it (filters are pretty predictable sets of options and rendering them would be form code with a little javascript, AFAIK). I'd guess more powerful servers and a better optimized database is the source. If they're planning to revamp the tools into web-only or web-enhanced forms, they're going to need a pantload of performance. We could simply be seeing that.
|
|
|
|
3 years ago ::
Oct 13, 2010 - 5:49PM
#89
|
Date Joined:
Nov 23, 2003
|
The fact that it still works with the prior page indicates that little changed on the AJAX interface side. (Someone had a copy of the page saved locally as a form of a bookmark, and it still can get the new data)
I never saw it as slow before, and it's not slow now (nor is it noticeably faster). So I'm not sure what they could have done to change that. As I mentioned before, the assumptions would be fixed some bad Javascript. If it were backend based, it would affect everyone equally. If it were connection based, it likely wouldn't be compatible. So that leaves front-end, which in this case is the browser. But I'd have to look at the old version to be sure.
"Nice assumptions. Completely wrong assumptions, but by jove if being incorrect stopped people from making idiotic statements, we wouldn't have modern internet subculture." Kerrus
Practical gameplay runs by neither RAW or RAI, but rather "A Compromise Between The Gist Of The Rule As I Recall Getting The Impression Of It That One Time I Read It And What Jerry Says He Remembers, Whatever, We'll Look It Up Later If Any Of Us Still Give A Damn." Erachima
|
|
|
|
3 years ago ::
Oct 13, 2010 - 5:51PM
#90
|
|
|
Please keep your posts polite, respectful, and on-topic, and refrain from making personal attacks.
|
|
|
