|
|
KNotations :: Documentation and development plans from the KnowNet development team
|
Weblog | 84 entries | 23-June-2006 | 1 authors |
|
|
Blog Entry | 1 reply | 07-September-2005 | Mike Malloch |
I find it annoying that the sidebars are all expanded while the page is loading, and then those which are cookie-d to collapse do so after page load. I recommend having a bit of js-written styling just before the sidebars ( so the main content loads that little bit faster above them ) and having those rules hide the about-to-load sidebar id's.
[ASIDE] - This is an extremely trivial note, of the sort that I write up as firstClass conference messages dozens of times every day. I'm posting it here because I'm trying to experiment with making our development notes more publicly visible, and also because in this case it kind-of documents the sidebar-collapsible feature and some design decisions which other developers ought to know about :O) I find it annoying that the sidebars are all expanded while the page is loading, and then those which are cookie-d to collapse do so after page load. It makes an odd and suddent transition in what the user sees, and makes 'pre-scrolling' very confusing. In case you didn;t know, the sidebars are each collapsible (click the little box icon to the left to toggle this), and the preferences are kept as a cookie. See the screenshots for before and after views o the sidebars during pageload. There is no need for this - we could easily set up actual display:none style rules before the page content loads instead of acting on the DOM nodes in javascript after pageload. That is, we dynamically write style rules into a little style block which come above the markup for the sidebars, and which declare that certain of the sidebars have the rule display:none applied to them ( the cookie specifies the id's for the selectors ) There are 2 choices for when/how to create the style rules:
Option 2 is best since the cookie only makes sense if js is enabled; otheriwise css-on + js-off could hide content irrevocably Also ZPT is darned awkward for writing style rules. It is easier to generate css rules as text in javascript and write them into the page than it is to use zpt :O) I recommend having a bit of js-written styling just before the sidebars ( so the main content loads that little bit faster above them ) I'll do that tomorrow morning. While I'm at it I'll have an initial look at having the categories sidebar written in js as a tree reflecting the categorical facets hierarchy. We found out today that very long category facet-chains cause a styling glitch in MSIE/win, and I've been meaning to make a js at clientside tree render / drop-down render for the categories for ages.
|
|
Done! - Quicker to do than to describe :O) | Discussion Topic | 0 replies | 08-September-2005 | Mike Malloch |
That quick feature/fix is done; sidebars which have been collapsed will be hidden before they start loading. I have not done anything about the faceted categories tree-widget; it's only a problem for us techies with our categorical fixations, and there is no time for it in the present rush to release.
I've implemented the write-style-rules-in-js solution. Took 2 minutes to implement, 5 to push past our draconian caching and 30 to describe :o) I'll look at the js writing of categories sidebar after we hit all the main release targets; almost all ordinary bloggers would never think of using loooong category strings like development/knotes/weblogs/features :o) But must remind ourselves to document the behaviour we already have with resspect to faceted categories like that. |