You are not logged in Log in Join
You are here: Home » Resources » Mozilla » ZWiki » MiscIdeas » wikipage_view

Log in
Name

Password

 
 
FrontPage » ZopeMozillaDashboard » ZopeStudio » ZopeStudioVision »

MiscIdeas

Must Read: WildUIThoughts

Misc Ideas Follow

Warning: None of these may make any sense. If you think something is useless, crazy or too fancy - it probably is.

  • Docking : One should be able to dock/undock various windows/panels from a main window.
    • This is dangerous. It looks simple, but I am not sure if Mozilla is technically up to it. I thought of it as well, but it is something very low priority to me. If you can deliver me a prototype that shows how to do it, I'll include it of course. People will expect to be able to drag a panel and dock it anywhere, and combine panels (with tabs for selecting them).
    • Linked Windows : Under some cases view_windows (propertyview, securityview, view, edit etc) get linked to manager_windows (objectbrowser tree, detailsview, tree with all object etc). This means selecting an object in the manager_window updates the linked view_windows automatically. Making this more generic - update and save in the edit_window automatically refreshes the view_window.
      • Generally, the Bottom right hand side, the Object specifics will do this kind of thing. If you select a different object in the mini browser, you get to see the properties for that object.
      • Smart Caching : The page designer will go through many edit/view cycles. He doens't want to make calls to the database (or even the zope server ?) every time he does a view. Enter Smart Method Caching (tm). The overhead for some methods is saved since the zope server (or even mozilla?) caches the results of the call and uses it as long as being viewed for designing purposes.
        • This is definitely a given. It is one of the goals (I should make this one explicit), Zope Studio should minimize calls to Zope servers.
        • Wizards : I hear about this in PTK and I guess what I'm thinking for ZopeStudio is similar (haven't looked at PTK wizards). A mechanism to define wizards - so that there can be wizards for creation of all kinds of objects and other things.
          • Yup. There is a Wizard framework in Mozilla which we can use.
          • Relocated Control Panel : Why is the Control Panel where it is - embedded right inside my website data tree? Irrespective of however it is stored in the object database, the Control Panel is a special folder with magical properties. I deal with it differently and than I do with other data folders. Shouldn't the Control Panel be somewhere else (Tools Menu - Control Panel, or how about this: the top level tree node for a zope server has two subnodes - "Control Panel" and "Website Root")
            • Convenience I guess. Also clarity for the code writer, for when he wants to access a Product directly, the visible Control Panel makes it clear what the path is. Also, it has to be accessible for ZClass? development. The server management stuff, like ZODB settings, can be placed elsewhere in the Zope Studio interface.
            • Merged View Windows : The user always wants the propertyview, securityview and some other views available but doesn't like to have so many windows open. So he merges all these into one window where they become separate tabs. He docks this window into another and it becomes a panel by the side of the edit view.
              • The bottom right hand panel does this. It should include security as well really.
              • Drag and Drop : Use wherever applicable :-)
                • Object browser: Moving, copying objects between folders
                • Editing: Drop dtml tags, other objects into the edit view window.
                • Blue Sky: When objects are dropped into the edit view they become appropriate tags (drop a dtmlmethod called color and it becomes <dtml-var name="color">).
                • Very Blue: Many times objects (say a dtmlmethod) are usually used with parameters passed to it. If some way is devised for any object to publish the common parameters, whenever it is dropped or viewed, the parameters to be used can be easily editable through a dialog/property box.
                  • I should have made the ubiquity of drag'n'drop in my ideas explicit as well. Hell, this is my first full swing UI app vision description! =) About the drag and drop of objects: Yes, I left it out because I want to be sure we can do it. And I hope that the Interfaces project will let you do the last idea. It certainly is something I'll need for the components; i.e. I want the popertysheet (bottom RH side, remember?) to show the properties for the currently selected component.

                  (I'm not done yet - more to come)

                  Hmm... after looking at the other interesting discussions going on in this wiki I've realized that these things are superficial. All the above is related to user interface and usability but deeper architectural issues have to be tackled. It's useful to keep usability ideas in mind though, so that we know what all should be possible. Soon I'll be putting up something worth a cent or two regarding the architectural issues too (related pages: ModelViewController, ZopeMVC).

                  • MVC is something for the longer term. The Interfaces project will have to solve our immediate needs. Basically, we'll make Zope do what we need it to do to reach our goals. --MartijnPieters

~Shalabh