[Framework-Team] content tab switching
Wichert Akkerman
wichert at wiggy.net
Wed Feb 28 01:16:23 UTC 2007
As you're all probably aware there has been some discussion recently
about the kss based content tab switching feature in Plone 3. I have
tried to get a good grasp on the situations and this is what I came
up with.
This discussions revolves around the implementation of PLIP 121
http://plone.org/products/plone/roadmap/121 . This PLIP documents
a single reason for doing in-place replacement of the content view:
performance. Only reloading the content view but keeping the rest
of the page in place should be a lot faster.
Looking at the current situations there are a few problems:
- the in-place loading behaviour breaks the back button. This breaks
user expectations and leads to frustration.
- one of the risks mentioned in the PLIP mentions is that the tabs are
no longer bookmarkable but says that we are willing to sacrifice this
for the speed benefits. Later user testing has revealed that this
might not be acceptable.
- at this moment the in-place reloading is not faster. The AT edit forms
are too heavy, so loading the edit tabs takes long enough to negate
any benefits from not reloading the whole page.
- javascript triggers do not work correctly when replacing the content
(autofocus, form unload protection)
This makes me think that at this moment we should not ship with the
in-place content tab replacement functionality enabled. The concept is
still good, but in order to realize the desired benefits we need more
extensive work: the edit forms have to become a lot simpler and cleaner
and we need to find a way to keep the browser history updated so the
back button keeps working. We might be able to take some inspiration
from what gmail does. It is definitely a direction in which we should be
going.
Opinions? Thoughts?
Wichert.
--
Wichert Akkerman <wichert at wiggy.net> It is simple to make things.
http://www.wiggy.net/ It is hard to make things simple.
More information about the Framework-Team
mailing list