The drawer is one of Apples real design errors. Kill it and replace it with a real good palette (I can put anywhere also on a second monnitor) like in Omni greaffle or Omni Outliner, etc…
wolfgang
I vote for less scripts and more real features
We’ve already discussed this internally but disagree. So as long as the majority does not agree with you, such a change is (at least currently) unlikely.
i agree with wolfgang. the drawer wasn’t really the best of apple’s interface ideas. not only omni group but e.g. adobe refused to jump on that train.
what bothers me more is the inconsistency: a drawer for the »einordnen«-button (don’t know how it’s called in the english-version), a palette for the »groups«, »find« and »information«.
and why do i have those »einordnen« ans »siehe« buttons, when i sort text-, rtf- and pdf-files but miss them when it is a web-link?
why do i find some data that i’m importing in the »incoming-folder« other stuff at the top level of the db hierarchy?
[/quote]
Here’s one of those instances when I will strongly disagree that drawers are a UI mistake. The drawer metaphor has advantages in certain circumstances and throwing this UI out for philosophical reasons doesn’t make sense to me. (Nor am I really very enamored of Adobe’s UI approaches, which often have a big learning curve.)
When I’m doing research I will often have two or more documents open in their own windows and with drawers from the ‘See Also’ operation attached to each.
Here’s why the drawer UI is a really good choice for that working environment:
When I use Exposé to display all of my open windows in DT Pro so that I can see the one I wish to bring frontmost, I can instantly identify those document windows that have ‘See Also’ lists ‘physically’ attached to them. That wouldn’t be true if the ‘See Also’ lists were palettes instead.
This is an example of how the drawer metaphor can make one’s working environment more useful and intuitive than if one used the palette metaphor for displaying that list of similar documents.
Note that I also really like the drawer metaphor for the Classify, Word and Option-click operations attached to a window. Exposé gives me a visible cue when I’m switching back and forth among windows.
So the drawer metaphor has real practical advantages over palettes in such cases. The overall UI is richer and more intuitive in such cases, which makes DT Pro’s working environment richer and more intuitive.
I’m using a word processor that attaches a number of palettes specific to each open document. When I’m working with a multi-document project and am in the process of adding TOCs for each document, I find myself wishing the developer had used a drawer for the TOC instead of a palette, as the palettes are not visible in Exposé. That means that I can’t instantly see in Exposé which documents are ‘finished’ and which ones still need work. That irritates me. 
So I use a kluge to let DT Pro’s UI keep me apprised of my progress. I index that folder of word processor files and assign the ‘state’ attribute to that group in my database. As I complete the TOC for each document in the word processor and save it, I check the state box for it. Now I can instantly review progress. When finished, I delete the state attribute for the group. But that’s more work, which in this case wouldn’t have been necessary if drawers for TOC elements had been used in the word processor.
I’m not arguing that DT Pro’s UI is in any way ‘perfect’ or finished. On the contrary, there will be attention to improving the UI in future versions.
But the emphasis on UI should be to enhance the usability of DT Pro for the user. Whatever one thinks of the early development of drawers in Apple’s UI, I think that Apple’s subsequent addition of Exposé to the overall UI makes drawers more user-friendly than palettes for some operations.
hi bill.
why counting pro’s and con’s? we should make a better use of our time.
drawers can do it, but for me the drawer metaphor is more a gimmick than a tool.
when my dtp drawer opens i can do nothing with it. it is too small to read any path or group name listed in it. this means, i have to draw it broader. this means further, that my monitor isn’t as large as it should be, so i have to scale down dtp’s main window. mph.
perhaps there is a hidden tool to change the main window/drawer width ratio generally and i still havn’t found it. then please show it to me.
I don’t think it’s necessary to resize the drawer, at least on my 15" MacBook Pro.
Hover the cursor over an item whose path is too long to be rendered. A text box will appear that contains the complete path.
Question: Would that meet your need to see a complete path? What about responsiveness, i.e. hover time lag before the text appears? What else would be helpful, e.g. clipping the path to the clipboard if that were possible?
I do make heavy use of ‘See Also’ when doing research and I like the visual cues provided by the list of suggested similar documents ‘attached’ to a document. I think of this as a ‘cluster’ of potentially related documents. I also use Exposé to switch among my open database windows, and appreciate the visual cue provided by the attached drawer when moving back to work on a particular document, or to a window in which I’m doing ‘housekeeping’ chores using the ‘Classify’ button.
At the moment I’ve got 14 windows open in DT Pro, as I’m working on a couple of projects. I’m a huge fan of Exposé and prefer it to other means of switching between open windows in DT Pro. For each project I’ve got at least one document open with an attached ‘See Also’ list drawer. I can identify those quickly in Exposé.
On my MacBook Pro I find it a more natural movement of my fingers on the keyboard to swoop the trackpad cursor to the upper left corner of the screen, then click on the desired window, than to use a keyboard shortcut, especially one requiring me to hit the Shift or Tab key as part of a key combination. But maybe I’m a nut. 
I wonder how many users make use of Exposé for window-switching in the frontmost application, or have tried it. For those who use Exposé in this way, visual cues (and there are others I use to distinguish among views, for example) become important.
UI issues can get pretty complex. In general, Mac applications should try to be as consistent as possible with Mac UI principles. Those principles, however, are not as simple – or consistent – as one might think at first glance, even in Apple’s own applications.
I think drawers attached to documents for operations such as See Also and Classify are an intuitive, visually representative way of displaying what are in fact clusters of suggestions related to a document. And that carries over well into the UI of Exposé. Those ‘clusters’ wouldn’t be attached to a document in Exposé if they were palettes (and unlike the first poster in this thread, only a small minority of users have two monitors). But are drawers the best or only way to convey such an expression of connection? Perhaps not, and suggestions for UI alternatives would be welcomed.
And then there are issues of consistency of operations across several types of documents in the database. In another thread it was pointed out that DT doesn’t use the standard UI for zooming HTML and PDF documents. That’s true, and that’s an issue for consideration in future releases of DT.
But the current keyboard shortcuts for zooming the view of all types of documents are internally consistent. As DT Pro works with a number of document types, shouldn’t the keyboard shortcuts perform the same regardless of document type? Personally I prefer the DT Pro shortcut for zooming (Control-Command-Up (or) Down-Arrow as more ‘comfortable’ than Shift-Command-Zero or Command-Minus, especially when the user is seeking and ‘fiddling’ for a comfortable reading size.
Note that an issue arises for text documents, as they use those ‘normal’ PDF keyboard shortcuts to increase/decrease the font size (rather than view size) of selected text.
So a consistency problem is inevitable. If text documents are to be zoomed with the ‘normal’ shortcut used for PDF documents, then another keyboard shortcut would have to replace the standard UI for text editing. We feel that an inconsistent UI for text editing would cause users more problems than the choice which has been taken, i.e. to leave the editing UI consistent with Mac text editing, and use different zoom up/down shortcuts that perform similarly for documents of all file types. Does anyone have a better suggestion?
User criticisms and suggestions for UI improvements are taken very seriously, as UI improvements are a priority for the next major release. User comments concern appearance and ‘look and feel’ issues, ‘Macness’, and fundamental intuitiveness and usability.
So please complain loudly and often!
We will appreciate suggestions on how a particular issue could be better addressed.
And even when we may not seem to agree with a suggestion, it may trigger an evaluation as to how something could be improved.
I am not really against drawers, and I think it is a bad argument to dislike drawers just because Apple doesn’t really use them. The fact is that there are many killer mac apps that still use drawers. (like every omni program, Bookends, and… well DA and DT). Although I am not against the Inspector style of doing things, I like that a drawer is actually connected to the window it is about. An inspector has to continually change its info based on the front window.
But I also have to say that Bill’s argument for drawers based on his expose would not be enough of a bonus to keep drawers if an Inspector style proved to be better. I use expose to move between windows alot too— but if you don’t immediately recognize which window you want, all you have to do is hover over it with your mouse to find out what it is, the addition of a drawer on the window doesn’t really add a ton for me.
If DT is serious about helping with expose, I would suggest perhaps making the windows for PDF’s have a different shade/color than an open webpage, and different from a different text page. I think this would go a long way to helping with expose use, regardless of whether or not drawers were open.
Hi, Dan. I was kicking around the idea that drawers really do seem an intuitive UI cue for cases where ‘clusters’ of associated items are tied to a window. A drawer pops out for ‘See Also’, ‘Classify’, ‘Words’ and Option-click.
Suppose I’ve got 5 document windows open, two of which are showing lists for a ‘See Also’ request.
If the drawer UI is used, I can instantly identify those two documents among many others in the Exposé view.
Otherwise, lacking a visual cue such as an open drawer, hovering over each document window still doesn’t tell me whether or not I’ve got a ‘cluster’ case. Hovering will only show me the names of the documents. I’ll have to remember by document name whether this is a ‘See Also’ cluster to which I wish to return.
Why use a panel for Info instead of a drawer? Because Info is common for all groups and documents. An Info drawer would not provide a unique visual cue but would instead weaken the effectiveness of the current cue that a drawer is associated with a cluster of elements (related documents, potential group locations or words used) tied to a document.
See, I’ve just about convinced myself that this makes sense. Anyway, I use it in my own work environment.
On the other hand, should the information in documents have a different appearance based on file type? If I’m researching a topic, why should I care whether the text I’m reading is held within a text, PDF or HTML ‘container’?
I think that making a UI look simple probably isn’t simple.
an i promised to discuss it on the list, because i think there are a lot more thinking like me.
wolfgang
thats why apple uses paletts in nearly all the pro (and no pro) tools? 
wolfgang
hi bill,
suppose I have DTP open all the time (during web research I do in the browser collecting snippets and pages with the services)
Its open on the “second” monitor. (MacBook display) I cant change that size so the DTP window is relativly small (3 pane view) for reading.
For “classify” and “see also” the DTP window needs to jump to shout out the drawer. Than I go back to check and the window jumps again and jumps and jumps…
If a i used to open a second DTP window on the main monitor too it has to be small (beside the browser). Hence are 2 windows jumping, jumping, jumping. I will need a lot oft money for the psychiatrist.
wolfgang
Hmm, I like the fact that when you open a drawer and the screen position is such that it would open off the screen, the window self-adjusts so you can see it.
Seems like a nice feature to me, as it saves me from having to manually adjust the window.
I didn’t even have to get therapy…
Hi, Wolfgang. How strange.
I always find discussions of Expose amusing: I have found it the single most useless (and annoying, until I disabled the keys) feature in OS X.
Having a UNIX background (i.e. using window managers like Enlightenment), I have become accustomed to using a combination of Virtual Desktops and Window Shades.
With virtual desktops I have an infinite amount of space, and everything is exaclty where I left it (like my keys!); no need to clutter a single workspace with all of my windows, or to minimize applications that are not in use.
With window shades, I can keep a fairly large number of related windows (terminals, viewers, editors) in a single workspace without competing for space: to work on a lower window, I shade the one above it and start typing (of course this requires focus-follows-mouse, which Apple apparently abhors as much as two-button mice).
It is fast, efficient, and lets me work with hundreds of windows (actually 20-30 terminals, 4 browser windows, 15 editor windows, and 5 or 10 documents viewers are constantly running on my typical UNIX box… of course OS X won’t stay up long enough to let me open all that, hehe) without any confusion or need to track down which window I am trying to do work in.
Expose is the opposite philosophy: the windows are moved around from where you left them in a ham-fisted attempt to help you find them. My initial reaction (“now THAT is a solution looking for a problem”) gave way to a stunning disbelief at how bad Apple’s “cutting edge” user interface was. Expose exists to help you find lost windows: if the Window Manager UI was designed correctly, you would never lose a window!
Well, enough about my rant on Expose and the OS X Window Manager. I could go on for days 
I don’t like the drawers in DT; they don’t work well with how I like to use the app. I operate DT in three-pane view with the inspector and groups window on the right and the log window underneath (which doesn’t re-open on launch, unlike the other two); it takes up an entire desktop. Opening a drawer from the viewer of the three-pane window means the drawer opens under the Info and Groups windows, which are top-level: I have to open the document in its own window to see the drawer. If I put the two top-level windows to the left, I have to leave room for the drawer on the right (waste of potentially useful reading/browsing space!) or DT will resize itself to fit the drawer – which, well-intentioned as it may be, I find annoying (“my window is not where I left it!”).
Obviously I am not using DT in the same was as Bill is. Documents that I have open for long-term purposes (reading, editing) are sent to the appropriate project desktops. My main interaction with DT as far as searching and browsing goes is as a single, maximized application, so I can take in as much information about a document (its metadata, its contents, its position in the hierarchy, its neighbors) as possible. I find that I rarely need to open an extra viewer window on this desktop for browsing and searching; once something is found, I shove it out of the way to another desktop where I will eventually work on it.
Bit of a longer post/rant than I anticipated. Should give some idea of alternate (non-Expose) usage I hope.
I think it has more to do with the fact that apple’s pro tools aren’t multi-window interfaces. A drawer is silly when you’ve only got one window (as per previous versions of mail.app). Where there’s multiple windows with different information, having that information physically hooked to the related window has some merit.
For some interesting insight in this issue, look at the debate about drawers versus palates over at the VoodooPad forum. When version 3 replaced the drawer with palates, the uproar caused the developer to put the drawer back. In the current implementation, there’s the option to use either (or both). While in theory I see the benefit for the palates, I find I use them but rarely whereas the drawer is a constant.
My $0.02.
I find drawers more effective than pallets.
In fact, I avoid using them and many otherwise excellent applications that only offer pallets as an option.
They may not conform to certain UI guidelines but I find drawers more useful.
by the way, edf: a better in-window navigation (tabs?) would help a lot to keep your window structure intact (just to mention the post about tabs…)
M
Could you explain how you use windows, and how tabs associated with windows could provide an advantage?
Do you make use of multiple open windows, e.g. to make it easy to move text into one window from another, or to read reference material in one window while one is writing in another?
My working environment normally involves a top-level view of my database, two or three views of different project groups, my Bookmarks group, several open document windows, perhaps set up so that I can work with a couple side-by-side, a floating document window that I use for a daily journal and notes, at least one Search window, very often the Groups panel (usually minimized to the Dock) and the Info panel. That floating journal/notes window is usually minimized in the Dock until I need it, and I’ll sometimes quit or minimize the Info panel if it gets in the way. That journal/notes window, by the way, is set up (using Afloat) so that I can call it up from the Dock to make clippings or comments on documents displayed in any application, not just DT Pro.
For me, this is a very efficient working environment. I don’t have so many windows open that I feel the need to maintain separate project working partitions, but I’ve got quick access to what I’m working on at the moment.
I’m familiar with and have a few tabs set up in Safari and DEVONagent. But a weakness of tabs (to me) – especially going beyond the common use in browsers – is that one can see only one window at a time. That’s probably OK in the context of DT Pro’s Preferences panel, where the General preferences are displaced when one clicks the Import tab.
Even in browsers, the utility of tabs can break down if too many tabs are used. I’ve got hundreds of bookmarks that are well organized in my DT Pro database. Many of them are scientific journals that I visit weekly or monthly, news sites that I check daily and governmental agencies that I visit frequently. I’ve set up my ‘new content’ preference so that rich note captures from a Web site are sent to my Incoming folder. I set up my Bookmarks view side-by-side to my Incoming folder. That lets me immediately see and edit each capture as it happens – perhaps I’ll need to rename the capture, or toss out extraneous material.
That’s why I do almost all Web captures ‘inside’ DT Pro. My preferred capture mode is rich text of selected text and images. But once in a while I’ll capture as an HTML page, or still less frequently as a WebArchive. Those options are instantly available as a right-click set of contextual menu options. And I can instantly move to the Incoming window to do any editing of the captured material.
This on the 15" screen of my MacBook Pro, though it’s prettier on the 24" screen of my Power Mac G5.
Now, an analysis of the efficiency of tabbed browsing. I loaded Science Magazine online from a bookmark in my database this afternoon. It took about three seconds to appear; that three seconds would have been saved had that journal been preloaded on a tabbed browser. I then downloaded as rich text notes, including images, 21 items. Each of them took 2 or 3 seconds to appear, and some several minutes to browse, to decide if they would be useful to me; in addition to those that I decided to download, I looked at 6 others that weren’t interesting enough to download. In all, including a couple of minor edits of captured material, I spent one hour and 22 minutes going through this week’s issue and capturing selected material. I’ll probably do a thorough review and perhaps make some notes about a couple of them soon.
In my Bookmarks subgroup for science sites there are 34 bookmarks. Yes, I do use all of them. Some every day or two, some weekly, some monthly, and some irregularly. That’s too many to put up as tabs on a browser, and that’s just the start. There are a number of news sites that I visit frequently, so I’ve got bookmarks for the Science page of the New York Times, and another for their Technology page – as well as other news sites including European and Asian sources. Now for my governmental agencies, as I do a lot of policy research. I’ve got bookmarks for a number of pages at the U.S. Environmental Protection Agency and several other federal agencies, a number of URLs for U.S. agencies in states (usually environmental agencies), plus URLs of interest in the European Union, China, India and several other countries.
There are more than a hundred more bookmarks I keep for various interests. I’ve organized my Bookmarks folder so that it’s much easier to find what I need than any other approach I’ve been able to figure out.
Do I have tabs set in DEVONagent? Yes, two. One for the DEVONtechnologies site, because I frequently access it to provide specific URLs to people, and one for this forum. As DEVONagent is my main browser, links that I click in other applications, such as a Mail message, will appear temporarily in other tabs in DEVONagent’s browser. And yes, it is convenient to switch between tabbed pages.
So I agree that tabs have utility in certain circumstances. But more than a relatively small number in a browser window gets unworkable (including truncated titles and/or running off-screen), aside from the fact that there’s something of a memory penalty for pre-loading a lot of sites. With fast broadband connections, there’s not a significant penalty for not having a site preloaded.
There have been comments about using a tab approach for ‘non-browser’ portions of DT Pro, and there may be some circumstances where that would be useful – again, for a relatively small number of items displayed by tabs.
For example, the top-level view of a database displays all of the groups at that level. So one might think about using something like tabs that display only a portion of the top-level groups, such as, e.g. References, Projects, Contacts, Personal and the like. One can already organize the top-level of a database like that, of course. But perhaps this could be made prettier and more intuitive, especially for first-time users.
Because databases are designed and organized in so many different ways by users, a tab approach, perhaps as a front end, should allow user flexibility rather than restricting the user.
Suggestions? (But remember the built-in browser in DT Pro isn’t intended to be a ‘full-fledged’ browser, although it’s very convenient for Web captures of notes, HTML or WebArchive material from the majority of sites.)
it seems as if this post becomes a general ui discussion. I made screenshots how I use my windows ( heres the exposé of all the windows and here is the normal view.
Since a few months, I use a lot of internal links (wiki-style and manually), because it helps me to think and later, when I write an article or a chapter, I can find the connections again that I had in mind before. I use “see also” in addition, but linking is important for documents with different content.
I usually work on drafts in a new rtf window. When I finished a passage, I select it and look for related documents with “see also”. Now it becomes troublesome: When I click on something, my window structure is lost, because the linked document opens in the same window where I write in. Because I work with links a lot, it takes a while to get back to the document I work with.
For example, I complete a paragraph in the draft and “see also” suggests document 3.a, where I find a reference to 060723-a-231 (which means page 231 ff. in the book with my bookends reference number 060723-a, by the way). there, I find an interesting “see-also”-connection to document 14.b47, from where a link refers to 060723-a-351. In safari, all this could have happend in a different tab (for reading reference) or in a different window (open in new window / open in new tab). At the moment, I have to hit the back button a lot.
By the way: html export does not help me, because file names in a folder like “0.a” and “0.b” don’t work out well: I end up having only one file “0.html” exported. I use the dot a lot in file names to make the wiki link more readable (e.g. 14.a24.b) - do I have to change this?) (off topic, probably).
But back to the ui: being able to open a link in a new tab or in a different window would help me to write and research at once. I hope this answered your question Bill - thank you listening!
Maak
I think a better UI would allow for effective use of tabbed windows, multiple databases, multiple windows and a drawer with concordant CMs of course.
The “Insert link to” CM is an effective use of the CM for example. We can currently move forward and back using the navigation bar above a given document though I suspect having access to a set of windows, via tabs, would be more convenient for many of us.