I'm looking at the database properties infobox, looking to move it to a property panel in Designer. When I say property panel, I mean putting properties in an Eclipse view at the bottom of the center of the screen, underneath the active editor. Like the infobox, this panel tracks the current selection. Someday the client may share this work, but for now this is for Designer.
The paradigm for changing properties in Eclipse is different from Notes. Both ways have their advantages... The non-modality and the volume of modifiable information available is a real benefit for the infobox.
But as I look at the db infobox, I see two kinds of information. One kind is informational or a launch point for a dialog (think archive settings, etc), and the other is actually editing the design. If I look at the same infobox for a db for which I don't have design rights, it's all mostly greyed out information.
So I'm thinking of a divide and conquer approach. In the Designer navigator, have a pseudo-design element, probably right under the database name, that lets you launch a database property editor. This editor would let you edit the stuff currently on the design tab, the advanced tab, the launch tab and a few strays - all very much part of database design. The properties box becomes more informational (and support the copy command for things like replica id!!) Things like size/archive settings stay in the property panel with buttons to change them today as they are discrete operations, not really design operations and are also allowed for nondesigner users. Header/footer stuff probably needs to stay in the property panel if the client will ever share this work, but would show the current settings (for BOTH header and footer) and then to change, you'd probably press a button that popped up a little dialog.
At first I was quite resistant to this train of thought - I like how the infobox works! But it's been growing on me (badly enough I woke up thinking about it), and I think should the client ever borrow this work it could greatly simplify the interface for the client, and that it gives a more natural editing experience for designers.
So was this a dream or a nightmare?
Subscribe to:
Post Comments (Atom)
7 comments:
I don't really care if you use an Eclipse panel or a property box that opens. As long as it is modal AND 10000000% seperate from the process of the client. The property box/panel should not cause me to not be able to switch to the client. It needs to be complete seperate space.
Personally, I would like it all or nothing. Half and Half will just feel like you didn't finish the job. Go all the way with Eclipse panels is my suggestion.
I think the Eclipse properties view would be appropriate for document properties, text properties, etc.
But the current Notes Database properties would probably work best in the main panel - similar to what you get when you edit a WAS web.xml file for a project in Rational Software Developer. This tabbed interface, with lists, checkboxes, buttons etc would allow the flexibility needed. As you point out - the current database properties dialog is actually more than properties, it is a way to set & launch a variety of things, and I think this 'profile page' approach would work best.
The challenge of course is to provide the same application properties to the client, the designer and the administrator, as many properties do not exclusively fall into one realm or another.
Sounds ok. I trust you on stuff like this, since you know much more about it than I ;-)
I like the idea.
I like the idea proposed by Michelle (2nd comment).
Maureen,
Have you seen some of the great ideas people have had about property boxes on Idea Jam?
http://ideajam.net
I think my thinking is closest to that of Michelle... That's the way we're leaning for now. We can always change it if we get feedback that says we should!
Did take a look at Ideajam... Making things copy and pastable was already on my mind :-) A lot of the requests are handled by Eclipse... The property panels can float or dock, if floating, they resize. They're written with Java layouts, so the resizing is a lot easier than with the current infobox code.
Thanks for the thoughts!
Post a Comment