Valentina Studio - Top 10 Impressions

[Ed Kleban]

On 12/20/05 12:56 PM, "Jochen Peters" <j.peters at valentina-db.de> wrote:

> Hi Ed!
> 
>> Here are my Top-10 initial reactions and comments:
> 
>> Central theme: The most scarce resource in any GUI application is
> screen
>> space, and VS is very wasteful of it.
> Well - GUI design has often been balanced between a screen full of
> all available information
> and a well structured presentation of only the relevant info - and -
> often the individual
> "taste" is different for different people.
> So - putting as much info as possible into the avaliable space can
> often be easily made
> with a DOS like screen approach :-):-)
> But general speaking i agree with you that we should not waste space!
> 

There is a tradeoff in the development of a design that helpful vs
detrimental based on how dense or terse the information is, or how
integrated vs how distributed that information is.  Consider for example, if
you are familiar with new and old versions REAL basic, or Internet Explorer
vs Safari the difference between requiring a user to open a new window for
every class or Web page, vs. supporting a multi-tabbed interface that offers
a higher-level mechanism for sanely managing a great deal of information.  I
was delighted to see that VS offers both.  Namely, you can have as many
windows open as you'd like, and the popup at the top allows you to
independently select the table(s) of your choice in each.

This is a completely different issue however from making the most effective
use of the valuable screen space you carve out in a window.

It's nice to have options for the former.  Abusing the later is merely a
sign of poor design and and poor accommodation of human factors.

But generally speaking, I suspect we are in heated agreement with each other
:-)


>> 1) I can use the preference to change the font displayed in the Schema
>> Browser, however that doesn't gain me any advantage vertically
> since it uses
>> HUGE icons that take up about two lines of vertical space when I
> set the
>> ont small to say, 9 pt Geneva.
> Yes - the simple reason is that the font info is currently not used
> in the Schema Browser -

You mean the data browser I presume, not Schema browser. I WAS able to
change the effecctive font size used in the Schema browser; once that is.  I
was able to change it to a small 9pt Geneva.  I've been less successful
since then in changing it again.

> so i will add that ASAP. We can easily adjust the icons to a
> reasonable height depending
> on the current font size. This will give you the possibility to use
> the vertical space in
> the Schema Browser more effective.
> That said the question is if we should need the possibility to define
> DIFFERENT font/font sizes
> for Schema Browser/Data Browser, what you think?
>

Do we NEED to?  That's an aesthetics and judgement call.  But I'd argue that
if the font can be changed it should by default change it for ALL displays.
If you want to have separate fonts for different kind of Browsers, heck that
would be great.  But in this age of Big screens with big resolutions, small
screens with small resolutions, users with good eyesight wanting small type,
users with bad eyesight wanting large type, and a half dozen other
preferences or reasons for wanting variable type size, the failure to
accommodate it in a modern app is bound to disappoint more users in my
opinion than having a preferences dialog with "too many" font options.
 
>> 2) In Column view, if I resize the window tall to include all the
> rows the
>> scroll bar disappears ‹ which is ok. If I then resize window to be
> short the
>> scroll bars do not reappear, which is a problem when you have a lot of
>> tables, especially since due to (1) above you can't gain back any
> screen
>> real estate by using smaller fonts.
> This seems to be a bug. Ed - it would be helpfull for us if you can
> report bugs
> in our bug tracking systems - we have a category for vStudio bugs in
> there.
> 

I'm generally quite happy to report bugs that I'm bitten by and feel
strongly about having corrected, as Ruslan will tell you and as you can
readily see on the Valentia Mantis list.  But in a survey report like this,
I'm offering first impressions and presuming the authors or others will
submit any issues that they consider to be bugs of sufficient problem that
it bothers them.  Eventually, yes I'll probably get around to documenting
these.  Right now, it's simply not a priority.  VS is low down on my list.
I've a backlog of V2 issues I'd far rather invest my limited time in right
now.

>> 3) Setting font to a smaller or larger size appears to have no
> desirable
>> benefits for the Data browsers.  It appears to change the height of
> the
>> header row, but does not change the size of the text displayed in
> any row.
>> It can therefore not be used to make shorter lines to view more
> lines in the
>> window, nor can it be used to see more characters across in headers
> for
>> narrow columns.
> This is also a bug! This has worked before - but as Ruslan mentioned
> the DataBroswer
> was completly rewritten - so - it seems we must reenable the use of
> the font info to
> size the rows accordingly.
> 

Two bugs and counting :)  That's a good thing to discover then.

>> 4) Selecting the "List View" option for Schema Browser in Preferences
>> appears to have no effect on newly opened browsers either before or
> after
>> relaunching the VS App.
> Yes - i have disabled the list view - it was not very usefull and i
> want first concentrate
> on the column view. If we will have the column view nearly perfect i
> will work on the list view again
> (in case we still need it)
> 

Then wouldn't it be a good idea to also disable the button in the Preference
dialog so users can see it's a feature under consideration that is not
selectable?
 
>> 5) Icons at the bottom of the Data Browser window impart a minimum
> window
>> width.  My first preference would be for these to either be
> optional, or go
>> away, or be stacked into two rows, or otherwise fixed so that I
> could make
>> my windows much narrower and therefore get more windows for more
> tables all
>> visible on the screen at the same time instead of having the right
> half of
>> the Data Browser windows showing useless blank white space.  If you
> display
>> a Data Browser for a related table it gets even worse, because the
> "Related
>> Table" tool bar doubles the minimum required width of the window.
> Well - for the "normal" browser this comes only in effect if you have
> - say - only 2 -3 fields
> in a table, right?

Correct.  And my database has a great many tables with few fields, not a
very few tables with a great many fields.  And until the lack of a lazy read
capability in V2 gets fixed, that will probably remain the case.  With my
style of programming however, it will likely always be the case.  So the
current design with the default layout wastes over half the space in all of
my visible table browsers.  And to be useful I need to be staring at 2 to 5
of them across the whole width, all at the same time.

Or is the VS layout only intended to be useful or optimal for people who use
the database in the manner that the VS designers deem to be "best", "most
common", or some other definition of "appropriate"?

There are LOTS of good solutions to this.  Most simple among them is to
simply not put an artificial minimum width restriction on the windows.  Let
the tools slide off the right side and become inaccessible unless the user
makes the window wider.  The way most applications such as Web browsers
accommodate needs like this to make display of toolbars and such optional
from the View Menu, so that the user can reclaim the vertical space as well.
Or add a preference setting if you feel novice users need to see windows
wide enough to view all the possible tools.   But I'll point out that you
currently don't do this for the Info inspector windows which open at a
narrower width than properly accommodates all the controls it holds and
therefore shows them falling off the right side of the window.

Sorry, in my opinion this is simply an artificial restriction that is
inconsistently implemented and has no reasonable justification if you expect
the tool to appeal to power users as well as novices.   And one might argue,
that the purcharser and user of a tool like this is far more likely to be
the former than the later.

> For the "related browser" - maybe you are right.
> On the other hand the
> options for the related browser are very powerfull and we must put
> them somewhere...
>

I agree 100%.  Good design conforming to the Apple HUI guidelines dictates
that they all be accessible from menus.  Tool bars are an extra.  But leave
'em in the tool bars as well.  Just be a bit more clever about it or less
restrictive in your window sizing limitations.
 
>> 6) That said, if GUI is going to steal massive amounts of otherwise-
> useful
>> screen space from the user's display, the least it could do is put
> something
>> useful in that space.  By default all of the columns are displayed
> in a very
>> narrow width that does not display either the full column headers,
> nor in
>> many cases the full data content even when 80+% of the window space
> to the
>> right of the displayed columns is blank white space that can note be
>> eliminated due to (5).
>> 
>> 7) Worse yet, column widths are not retained.  So if I adjust the
> width of
>> all the columns to make the headers and data visible and then
> change the
>> "Table:" from the pop menu at the top of the window, then later
> return to
>> this same table I then have to manually resize all of the columns once
>> again.  What an incredible pain in the rear!
> I think the main point here is storing the width of the columns,
> right? That way
> we can use the otherwise wasted space. Yes - this must be done. For
> this we need
> to store this info along with any table in a database. I have
> discussed this with
> Ruslan before - it is simply not yet implemented.

No problem.  Always nice to have a good list of features on your "to do"
list.  I'll look forward to it.  In meantime I'll enjoy the finger exercise
and look for a softer cushion to sit on.

>> 8) I appreciate it that when I select a record, that one
> (unpredictable)
>> field is highlighted.  I do not appreciate the fact that it is
> highlighted
>> in a manner such that if I type any character on the keyboard the
> contents
>> is then CHANGED.  I would far prefer to see it highlighted in a
> manner ‹ or
>> not at all if I just click on a row number (recId) that requires me to
>> explicitly click on the cell to begin cell editing.  Especially
> since there
>> is no UNDO so if I accidentally change a value and don¹t recall its
>> (potentially very long) previous value, there's no way to restore it.
> No - wrong. You can press "ESC" to restore the previous value.

Good to know.  And incompatible with standard UIF guidelines.

> And note
> that the record is saved only if you go to another record!
>

Also good to know.  And thus clinching the fact that this NECESSARILY is a
tool for power users in its current form.  Use by novices of a tool like
this that does not require a "Save" to confirm edits is simply an
accommodation to a request on their part of the form: "please screw me and
my data".
 
>> 8a) BTW when I change a field as described in (8) does VS
> immediately write
>> the new value to the table?
> No - see above.
>

Right.  See above.
 
>> Or does it keep a local copy that is only
>> flushed to disk for real when I do an explicit File Save
> operation?  Since I
>> don't see either a File Save or a File Save As on the menu I'm
> guessing that
>> my database is instantly corrupted as soon as I type a character as
>> described above in (8).
> 
>> 8b) Is there any way to use VS in a "read-only" mode, such as the
> way you
>> can use BBEdit or TextWrangler.  I of course opened VS on a copy of my
>> database out of paranoia, but if I need to explicitly write protect
> a large
>> database before using VS on it to protect myself it would be good
> to know.
>> I was not able to find any available documentation for download on
> the VS
>> tool.
> Well - Read-Only made can be done very easy, i think. Maybe we should
> do that? Ruslan?

Actually, the way BBEdit, and it's newer freeware replacement TextWranger,
do this is to phyically lock the file they opened when you click on the
little write-only icon at the left end of the tool bar.  Easy to do.  The
question is, what happens when you open VS on a write-protected file? --
Which I have not tried.

> The documentation will be available shortly after releasing the final
> version.

I look forward to reading it.
> 
> 
>> 9) I would really appreciate a non-metalic Schema Browser window,
> or at
>> least an option for such.
> Ok - can be easy added as a option.
> 

I and numerous other Mac users who share this highly-charged religious
viewpoint offer our thanks in advance :)

>> 10) The "Action" pop-up as the Finder window tool-tip calls it
> (button with
>> gear icon) does not pop up on mouse click and hold as is the
> convention for
>> this popup.  It only opens upon unclick.
> Ok - this can be changed, too.
> 
> 
> 

Great.  That should keep you busy for the next 5 or 10 minutes at least.
The above "hit-list" of impressions aside, I'll comment that except for
crashing once, VS performed valiantly and did in the end with the co-use of
the RB debugger end up showing me exactly where my logic error was, and has
provided an new educational or confirmation viewpoint or two on data
structuring that will have an impact on how I use VB.  And that is certainly
high praise.

Keep up the good work.
--Ed