Friday, December 28, 2007
Saturday, December 22, 2007
the cards not written....
I started my Christmas cards this morning. Very late, I know, but got a good start.
I go through my address book, writing out the cards pretty much alphabetically (somehow my mom's card is always first!) But this year, I paused when I got to two names... My Aunt Carol, who died too young at 71 in August.... One of the sweetest ladies to ever inhabit this planet... And Steve's grandmother, who died in April at almost 103... An amazing lady! I felt their absence as I wrote the cards out... I send them Christmas wishes in spirt, if not with cards and stamps...
I go through my address book, writing out the cards pretty much alphabetically (somehow my mom's card is always first!) But this year, I paused when I got to two names... My Aunt Carol, who died too young at 71 in August.... One of the sweetest ladies to ever inhabit this planet... And Steve's grandmother, who died in April at almost 103... An amazing lady! I felt their absence as I wrote the cards out... I send them Christmas wishes in spirt, if not with cards and stamps...
Sunday, December 02, 2007
database properties on my mind....
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?
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:
Posts (Atom)