Ah, you should aspire to more...Jon wrote:We at Sonny Software can do only so much to right society's wrongs…
Jon
Sonny Software
GUI sneak peek
Jon,
Kuddos on the extra field work. A concern...
I'm late coming to the game, but have you articulated why you're going with a drawer in lieu of a scrollable window view? I presume it has to do with the desire to have the vertical expanding notes field at the bottom of the window.
Before you made this decision, were you aware that there is alot of hate out there for drawers in aqua? Just google:
hate drawers
and you'll see the tremendous debate. (The fact that such a vague reference brings up on topic hits in Google reveals how big an issue it is.)
Many users will not welcome the use of them for anything other than:
1. Click to reveal the drawer containing controls.
2. Adjust the controls.
3. Click to close the drawer.
The Aqua UI Guidlines stipulate this type of use as the acceptable intent of a drawer. Apple itself got it wrong with Mail.app, but they later fixed it.
This use of drawers that you have developed is a questionable choice given the current Aqua UI standards, and it will alienate some.
Drawers, when they must be tolerated, are supposed to be opened in order to accomplish some quick task and then closed.
I'm going to always want to see the call number field, so now I'm forced to have this akward drawer open? ugh.
And even more so, the greatly desired extra User fields, when used by a user, are going to be very important to that user... something they'll always want open. Drawers are a poor UI design for anything that must remain open.
And which is more... the result you now have is that some fields are hidden with a hidden area revealed by a disclosure box and some other fields are hidden with a drawer. This is a bad UI, since it creates the final result of an arbitrary distinction between those fields that actually is not there.
This notion of having a drawer open is a tremendous downer for me. I work by having the Bookends window open in one half of the screen and either a WP document or a web browser window open in the other half. The necessity of having a drawer open is then destrows this work flow.
What is the problem with a scrollable window view, with perhaps the addition of a second hidden discloser area if you prefer?
Just trying to be helpful... I want Bookends to be the best it can be, too.
Kuddos on the extra field work. A concern...
I'm late coming to the game, but have you articulated why you're going with a drawer in lieu of a scrollable window view? I presume it has to do with the desire to have the vertical expanding notes field at the bottom of the window.
Before you made this decision, were you aware that there is alot of hate out there for drawers in aqua? Just google:
hate drawers
and you'll see the tremendous debate. (The fact that such a vague reference brings up on topic hits in Google reveals how big an issue it is.)
Many users will not welcome the use of them for anything other than:
1. Click to reveal the drawer containing controls.
2. Adjust the controls.
3. Click to close the drawer.
The Aqua UI Guidlines stipulate this type of use as the acceptable intent of a drawer. Apple itself got it wrong with Mail.app, but they later fixed it.
This use of drawers that you have developed is a questionable choice given the current Aqua UI standards, and it will alienate some.
Drawers, when they must be tolerated, are supposed to be opened in order to accomplish some quick task and then closed.
I'm going to always want to see the call number field, so now I'm forced to have this akward drawer open? ugh.
And even more so, the greatly desired extra User fields, when used by a user, are going to be very important to that user... something they'll always want open. Drawers are a poor UI design for anything that must remain open.
And which is more... the result you now have is that some fields are hidden with a hidden area revealed by a disclosure box and some other fields are hidden with a drawer. This is a bad UI, since it creates the final result of an arbitrary distinction between those fields that actually is not there.
This notion of having a drawer open is a tremendous downer for me. I work by having the Bookends window open in one half of the screen and either a WP document or a web browser window open in the other half. The necessity of having a drawer open is then destrows this work flow.
What is the problem with a scrollable window view, with perhaps the addition of a second hidden discloser area if you prefer?
Just trying to be helpful... I want Bookends to be the best it can be, too.
One of the drawbacks of Endnote (among many) is the long reference entry window that doesn't fit on a screen. Wider is preferable to longer for reference entry.
I don't understand what the problem is with a drawer opening in reference window or what having a reference entry window adjacent to a WP doc or web page is used for?
I would prefer call number in the 'main' window, however.
Is it feasible to have a preferences pane that allows a user to choose which fields to show in reference entry?
Also, can tab from field to field be more logical? ie in journal entry tab goes journal-volume-pages-date, when journal-volume-date-pages is more logical.
Thanks
Sue
I don't understand what the problem is with a drawer opening in reference window or what having a reference entry window adjacent to a WP doc or web page is used for?
I would prefer call number in the 'main' window, however.
Is it feasible to have a preferences pane that allows a user to choose which fields to show in reference entry?
Also, can tab from field to field be more logical? ie in journal entry tab goes journal-volume-pages-date, when journal-volume-date-pages is more logical.
Thanks
Sue
Hi Joe,
I don't hate drawers, and I think they work pretty well in Bookends 9. I doubt many people work primarily in the reference window view -- from the feedback I get, the List View seems to be preferred (and has a useful drawer, BTW). Second, if there is a critical bit of information that you feel you must always have in the main reference window view, you can move it there (user1-user4 are available) -- there is nothing inherent in Bookends that forces you to use the drawer for, say, Call Number. Just rename User1 in Preferences, say (and adjust any filters you use to direct the call number, if available, to this field).
I'm also not sure why you care about the disclosure triangle in the center of the reference window -- don't use it. It was added primarily for people with small screens (iBooks running at low resolution). It is "open" by default.
Finally, as for Google, I did a search for martian radioactive hamsters, and got 535 hits, which says something about a threat I never even knew existed.
Jon
Sonny Software
I don't hate drawers, and I think they work pretty well in Bookends 9. I doubt many people work primarily in the reference window view -- from the feedback I get, the List View seems to be preferred (and has a useful drawer, BTW). Second, if there is a critical bit of information that you feel you must always have in the main reference window view, you can move it there (user1-user4 are available) -- there is nothing inherent in Bookends that forces you to use the drawer for, say, Call Number. Just rename User1 in Preferences, say (and adjust any filters you use to direct the call number, if available, to this field).
I'm also not sure why you care about the disclosure triangle in the center of the reference window -- don't use it. It was added primarily for people with small screens (iBooks running at low resolution). It is "open" by default.
Finally, as for Google, I did a search for martian radioactive hamsters, and got 535 hits, which says something about a threat I never even knew existed.
Jon
Sonny Software
Hi Sue,Sue wrote:I would prefer call number in the 'main' window, however.
Is it feasible to have a preferences pane that allows a user to choose which fields to show in reference entry?
Also, can tab from field to field be more logical? ie in journal entry tab goes journal-volume-pages-date, when journal-volume-date-pages is more logical.
Yes, there is already a Preference for just that (Reference tab). You can use User1, 2, 3, or 4 for Call Number if you want it in the main reference window (and if necessary adjust any import filters you use accordingly).
As for tab order, sorry, it reflects the "control order", which is part of the structure of the GUI. (BTW, and not to start a discussion about what is a preference, I long ago set it to journal-volume-pages-date after feedback from others that I agreed with -- in scientific references the volume is almost always followed by pages).
Jon
Sonny Software
"Yes, there is already a Preference for just that (Reference tab). You can use User1, 2, 3, or 4 for Call Number if you want it in the main reference window (and if necessary adjust any import filters you use accordingly)."
Is this a case of fields being available for reference types? What I had in mind was being able to show or hide reference fields in reference entry window - the fields would still be available.
Sue
Is this a case of fields being available for reference types? What I had in mind was being able to show or hide reference fields in reference entry window - the fields would still be available.
Sue
This does make the questionable UI choice less of a problem.Jon wrote:I doubt many people work primarily in the reference window view
I care about it because you asked for feedback, and I gave it. From a programmer's point of view, it represents an arbitrary mixing of views--namely, a concealable view containing some fields, and a drawing containing others.I'm also not sure why you care about the disclosure triangle in the center of the reference window -- don't use it.
While quite funny, I'm not sure why you tip toe around the issue that many, including Apple, have with drawers. My point regarding the Google search was a valid one. You gave as your defense that you don't hate drawers, but I would've thought your goal would be to make an app that more than just you don't hate.Finally, as for Google, I did a search for martian radioactive hamsters, and got 535 hits, which says something about a threat I never even knew existed.
I tried to state it subtly earlier, but you didn't respond so I'll state it with greater clarity. This use of a drawer view is non-compliant with Apple's UI Guidelines regarding drawers. They are reserved for use as a view for controls/preferences, etc. It is specifically discouraged from uses such as content identical kinds of content to the main window, albeit less important. A non-chalant attitude towards the UI standards is not something that I welcome in Mac programmers I have (hopefully not mistakenly) chosen to support.
So, you never answered my initial question... why did you choose to go with a drawer, which is a clunky way of avoiding a scroll view for the window, where you could've just as easily added a second disclosure triangle view to toggle the extra fields out of view in a vertical scrolling window view?
In other words, what's with the scroll bar hate?
In other words, flexibility.jweaks wrote:I care about it because you asked for feedback, and I gave it. From a programmer's point of view, it represents an arbitrary mixing of views--namely, a concealable view containing some fields, and a drawing containing others.
One of the things I've always disliked about EndNote is that one has to scroll to get to the information needed (in my case, the abstract is usually the most important piece of information). Bookends has always shown all of the data at a glance, which I much prefer (and for which we've gotten a lot of postive feedback). The drawer is just another way of showing/hiding information with a click, much like a disclosure triangle. The drawer can also be made larger/smaller to suit your needs (if you want to see the call number at all times, say, you can make the drawer quite small). Once Bookends 9 is available everyone can decide for themselves how well it works and return for comment.In other words, what's with the scroll bar hate?
Jon
Sonny Software
Jon,
Thanks for providing your reasoning. I do think the ignoring UI Standards issue is not a small issue, though.
Just see how mail.app had a similar poor use of a drawer that had to stay open in 10.1, .2, & .3, and then finally corrected it.
But, I suppose a programmer lives and dies on her/his opinions.
Cheers.
Thanks for providing your reasoning. I do think the ignoring UI Standards issue is not a small issue, though.
Just see how mail.app had a similar poor use of a drawer that had to stay open in 10.1, .2, & .3, and then finally corrected it.
But, I suppose a programmer lives and dies on her/his opinions.
Cheers.
Not to prolong this unnecessarily, but I believe that in fact the drawer as it is implemented in Bookends 9 will remain closed for most people most of the time. First, the reference window is used when entering data by hand or confirming some information not available in the List View drawer. Second, the drawer contains information that is not often vital (call number, language, etc. -- and if any of it is vital to a particular user, it can be moved to a user-defined field in the main window). It is my guess that most people will not consult the reference drawer very often (if you dislike the drawer here, you should really dislike it in the List View, where I image many people rely on it).jweaks wrote:I do think the ignoring UI Standards issue is not a small issue, though.
Just see how mail.app had a similar poor use of a drawer that had to stay open in 10.1, .2, & .3, and then finally corrected it.
Absolutely.But, I suppose a programmer lives and dies on her/his opinions.
Jon
Sonny Software
Jweaks, I agree with you completely: while it's wonderful that the extra fields are there, the drawer looks just AWFUL. And as you may have noticed, Bookends doesn't behave like a full-fledged OS X app. Try resizing a library window, for example: you see outlines, rather than getting a live resize.jweaks wrote:Jon,
Thanks for providing your reasoning. I do think the ignoring UI Standards issue is not a small issue, though.
Just see how mail.app had a similar poor use of a drawer that had to stay open in 10.1, .2, & .3, and then finally corrected it.