[Zope3-dev] ZopeTop (the new Zope3 replacement for ZMI)

[Gary Poster]

On Friday 05 April 2002 12:27 am, Lalo Martins wrote:
> Ok, development of the ZopeTop is officially starting.
>
> One thing we discussed on #zope is the folder tree and the use of frames.
>
<@kosh> frames are a pain from a browser
> perspective and from a web app perspective 

<snip>

> 20:10 < lalo> but having a folder tree is good
> 20:10 < lalo> no?

yes

> 20:11 <@kosh> having a folder tree is fine however it should not be in a
> frame 20:11 <@kosh> make the page lighter and just reload the entire page
> 20:13 < MikeFair> A script based folder tree? or massive numbers of page
> reloads? 20:13 < lalo> dunno
> 20:13 < MikeFair> (and make sure you save that script before you navigate
> that tree) 20:13 < lalo> page reloads can be a problem

IE5+, Moz/NS6, and Flash 5/MX all allow script to load XML behind the 
scenes, without an actual page load.  If you want to demand a 
non-frame-based solution, I strongly suggest that as a solution.  page 
reloading of an entire page to see another part of the folder tree is not an 
option (as someone pointed out, you will be on the results side of a form 
submission quite frequently).  loading the entire tree in script is *not* an 
option (even if you cache the script by having it in a separate file) because 
the trees that many Zope users will be building will be gargantuan, if Zope 2 
usage is any indication.  You don't want to have to build and send a full 
file tree to every user that goes to a management page.  Completely 
impractical.

So, if you want a non-frame-based tree, loading partial tree XML behind the 
scenes (without page loads) *is* your option, IMO.

Let's hypothetically say we've settled on these requirements:

  1) Management interface does not use frames
  2) works on as many browsers as possible
  3) includes a folder tree

If I were required to build this interface and those three requirements given 
to me, I would *strongly* urge that the folder tree be built as a Flash 5 
widget.  You don't have to deal with the conflicting JS DOMs (even today a 
pain for unusual stuff), you get *more* potential audience (I don't know if 
Opera or Konqueror can load XML behind the scenes natively without a 
pageload, but I know that NS4 can't; I believe all three can use Flash 5), 
and you then also have an XML interface for getting tree information on the 
back end which might still be useful for Mozilla XUL interfaces etc. and in 
the future if the browsers ever all agree on behind-the-scenes XML loads.

> 20:15 < lalo> interestingly, I observed that only "power users" use the
> folder tree in Windows Explorer and Mac Finder 20:15 

This relates to usability testing for Zope.  I would argue that most Zope 
content managers are likely to be equivalent to "power users" that you 
describe--but our arguments are arguably pointless.  Guido mentioned Steve 
Krug's excellent, and short, _Don't Make Me Think_.  Krug points out that 
guessing and randomly extrapolating mean nothing: usability testing with the 
intended audience means everything.  He certainly convinced me.  While I am 
not in any practical position to help with that, that *needs* to be something 
that is done to any shipped Zope 3 UI.

> 20:17 < lalo> when using mozilla we could rely on xuf, rdf and the sidebar

And we could probably use the same XML functionality that the Flash widget 
would need...

< lalo> kosh: separate window,
> not frame
> 20:17 < lalo> a real window

I don't like little floating "remote control" windows.  But I suppose if that 
were my only option for getting a tree then I could deal.

> Srichter suggests we could make them an option. (Defaulting to off?)

I think this would be wise, if very little time were required to implement it 
(i.e., if we could mostly use Zope 2 code)

> You could also have a script (ecmascript, javascript) based
> folder tree - that would be even better, if you could
> right-click on an item and select specific views.

See above

> In the first stages, ZopeTop just won't have a folder tree. But
> I'd like to have this discussion here and collect ideas for
> adding them later.

Sounds reasonable.

Thanks for your work on this.

Gary