should database (application) properties go in Designer??
We'll be adding some new ones, so we'll need more room to complicate the issue further.
Historically, they've been in the selection hierarchy of any infobox. Changes are immediate, and not batched in a transaction like form or view or any other design element editor.
With the first release of Designer in Eclipse, we'll have a mix of infoboxes and property panes (unless of course users decide they'd rather wait for us to rewrite all the infoboxes before releasing it...)
Two questions:
- is it ok to remove database properties from the infobox selection hierarchy in Designer (where infoboxes remain)?
- is it ok to have to click on the database header in the bookmarks or make another gesture to get to database properties?
thank you :-)
Subscribe to:
Post Comments (Atom)
7 comments:
yes, both are fine. In fact, I find it more logical when the db properties are in the design pane like any other design element.
we definitely need to be able to see db properties *somewhere* in designer. the most intuitive place for me would be, you click somewhere at the top, maybe the db name underneath the twistie part, and it would appear in the place where the other info boxes appear, down below. the tabbed model maps well to what we know today. at first blush, that's where i'd put it.
I think this is generally an OK idea. I can't really envision how the new configuration would work, however. For instance, I'm not sure how the "property pane" would function. I haven't started using Notes 8 yet, so that may be more obvious to others.
It sounds like in Designer in Eclipse, we're moving away from the infobox? I have no great love for that interface to the design properties. So would this move of the db properties to a "property pane" be representative of how you see access to all design element properties in the future?
*IF* I understand you right, and you mean that application properties will be moved out of an infobox and be available in the Designer somewhere, then yes, I think that sort of consolidation make sense, especially the launch properties of an application.
The properties don't need to live in the infobox. Actually a full page in Designer would be cool. It could live at the same level like Frameset/Pages/Forms etc. The top seems to be a good choice.
:-) stw
Seems ok, as long as some db properties (info, printing and full text come to mind) are available without access to Designer.
both is fine, and it is more logical
Post a Comment