In the meantime, of course, the Split view removes that empty column, which is reserved in the Three Panes view for display of groups, if any, within the Global Inbox.
This doesn’t work for me; when I have it selected, imported files still go to the global inbox.
That’s an option in Preferences > Import - Destination. Select group will, when a new item is to be sent by a script, Service or Bookmarklet, pop up a panel that allows choice of the destination by database and group.
Just selecting a group in a database view doesn’t invoke that preference.
My experience is that it will not work for all scripts, so if it should I can file a bug report. The folder action scripts will still send documents to the Inbox regardless of the preference setting. Here’s a thread where I mentioned what I needed to change in the script to get it to work with the Select Group preference. I did not know that scripts should also work with Select Group or I would have reported it before now. Link
DT2 is undoubtedly an improvement over 1.5, and has encouraged me to start using it again after a hiatus. In particular, the multiple databases, Inbox and the new side panel all help enormously. But the comments on the UI here are well made, well meant and generally constructive.
The blank pane in 3-panel view when viewing the global inbox is not information, it is empty space. This, perhaps, is the most egregious example of the sometimes unpolished nature of DT’s UI. It is not the UI is actually bad (although it has its moments); it is that it is mediocre, and on the Mac mediocrity tends to look bad, because of the high quality of “fit’n’finish” of so many other applications.
Since I believe that all criticism should be constructive, here’s an(other) idea. Would it be possible to put the second vertical pane in the bottom half of the side panel, and have the top half, which would contain the global inbox, open and recent databases and so forth, collapsable? The blank pane would be less of an issue in this case. I’ve attached a hasty mock up to show the general idea.
No, I realise that, and already had the option set to “Select Group”. It simply wasn’t having any effect. I was under the impression that it applied to dragging files to the Dock icon, which is what I had been doing. I’ve since tried with with a bookmarklet, and it works fine there. Is dragging to the Dock icon not included in this function?
Not yet.
No problem. Thanks for the reply.
This is intentional as folder actions are automated tasks and a group selector popping up all the time could be very annoying.
Well, I’m glad I started a conversation. But filling an empty column with folders in the global inbox is not self-evident, and thus seems to me to be - at least - clumsy interface design. As an ardent user of DTP Office, I look forward to UI developments, because software usability is in UI design, and the productivity boost of good interface design should not be a luxury but a requirement for software on OS X.
Looking forward to seeing how things develop - and my comments, as with everyone else’s I’d assume, are made in the context of DTP’s beta status, when feedback is at its most relevant.
Rather than try to explain how confusing the ‘Inbox’, ‘global inbox’ is I’d suggest the developers check out two other programs with clipping features that are easy and reliable. I’d much prefer to use DT for all data collection but the UI is just too frustrating.
Notebook
SOHO Notes
I’m searching now for a PIM and have downloaded almost all of them and tried figuring them all out…it’s gotten to the point where I’ve forgotten that if I buy one and find out in a month I’d rather have the other…well, it’s not prohibitive unless I’m outta cash. So I don’t need to panic over the fact that I may buy one now and want a different program later.
So the two I like best out of them all so far are Journler and DevonThink. For me, DevonThink is overkill and not enough Mac-like, as the interface is just not so user-friendly and attractive. But Journler reminds me soooo much of Scrivener (a writing program), which I couldn’t live without. Its user-friendliness is the name of the game for me and both Journler and Scrivener are powerful yet beautiful programs that you don’t have to keep changing the screen on to make things happen…it’s like ALL on one screen and just about everything is 'edit’able.
I think DT will do more than I know…but it would just take some time for me to learn. If I could ‘edit’ my own documents in the lower pane of DT, that would make it more attractive, but I can’t find a way to do that w/o jumping over a lot of Windows-like hoops, if at all. In both Journler and Scrivener I can make a folder just for notes if I want, with the split screen.
I know nothing about how hard it is to program these things, but if DT would model its interface like Journler, I’d buy it today. But for my purposes, the ease of using Journler and its excellent interface sells it for me. When I see the day that DT does the same things, I’ll buy it too. One thing I really like about DT is its thumbnail images, Journler has them too, but are not as nice looking on the page.
So I hope somebody is listening…all we want is pretty and easy. Shouldn’t that be pretty easy? 
I think the simple elimination of the the double menu panels for Global and Individual Database would go a distance toward cleaning up the UI. I, too, vote for the inclusion of the separate global and specific (selected) database views on the same blue pane. Even if the solution was to incorporate the global view but have the option of hiding/revealing it by dragging a portion of the pane up or down, for me that would be less clumsy and cluttered than having the panels duplicated separately and governed by horizontal hide/reveal movement. This would also help those who operate with smaller (narrower) desktop screens or <17 inch laptops. IMHO.
I’m going to agree with this as well. Right now there are two side panes, and they are very different (one is blue, with OS X standard badging; one is grey, with number of contained items in parentheses). This really bugs me; it’s inconsistent. Unsure if splitting these vertically makes more sense or not.
I am always working in the 3-pane view, which is pretty much how every other app in this space (Together, Eaglefiler, etc.) handles it. DTP’s search is fantastic, but there are many UI things that continue to grate on me 
One more “me too” for integrating sidebar and database list pane into one panel.
I’m on a 23 inch display, but I still can’t use the sidebar because it wastes to much screen space. I need several windows open side by side. I want to see my content, not empty UI space.
Of course I can hide the sidebar and only show it when needed. But there are two backdrops with this approach:
- The global Inbox is out of sight and accessing it needs several steps.
- opening the sidebar makes the rest of the window too small to be usable anymore. So a quick switch to an other database to select and look at a document without opening a new window or doing a lot of resizing of windows and panles is not posible.
Both issues defeat the benefits of the Sidebar. While the Sidebar gets more useful with each beta, it is still not usable for me.
Johannes
Is there someone at Devon who is familiar with how most people use DT but isn’t familiar with its technical architecture? I think letting that person take a crack at the UI would improve it. I don’t think DT looks like a windows app (or a mac app), it looks like the sort of UI a programmer would develop for one of his own applications.
I’ve used DT for years now and I appreciate its power. I have a feeling the UI will never make any sense to me until I understand how it’s put together under the hood though. I don’t think that should be necessary.
While I agree with you that the UI could/should be improved, I would say: it’s not that simple.
From what I read in the forum there is no single way of using DTP that most users follow. To create a straightforward Interface that suits one workflow will hurt the workflow of more others.
I don’t think you need to know what’s going on under the hood, but you need to know the concept(s) and principles behind it. That’s the price for power and flexibility of any app. If you want an easy UI take iPhoto, if you need power and flexibility you need to deal with the complex concept of Aperture. None of the Pro Apps I use is simple to use out of the box. But they are powerful.
I have to disagree here. Before anything else you need someone who is good in UI design. And knowing the technical architecture of the program is necessary as knowing the intended workflows of the users.
Johannes
It’s true that you cannot design an app that reflects how absolutely everyone thinks about their workflow. Right now, the interface reflects how its programmers think about it. I am suggesting that designing it to reflect how the majority (not all) of their users think about it would be an improvement. There’s a good paper that explains what happens when developers try to design for everyone and it concludes that they end up basing the design on how they themselves think about the task space because it’s impossible to design for everyone. I think all designers have found themselves in that position at one time or another because they didn’t have access to users for some reason and we know that’s what happens (so that paper isn’t really news to us). That’s why step one in design is determine who your users are then do some research on how they think about their work.
Both of your examples follow the mental model of a “photographer” instead of reflecting the underlying mechanism of the applications. So, I agree with your first statement to a point. If the UI requires us to understand how it works “under the hood” then it does provide the end user with more power and flexibility. Your examples aren’t illustrative but if you look to open source apps, developed by programmers for other programmers, you’ll find a lot of good examples there.
By “familiar” I meant someone who was not involved in any way with the design of the technical architecture. Yes, someone who is “good in UI design” would be wonderful, but, to me that means someone who will privilege the end users’ mental model of the task space as opposed to the engineers’. There’s a paper from way back in 1990 that explains why it’s a good idea to have someone other than the person who designed the technical architecture design the UI. To a good engineer, a great UI will reflect the underlying mechanism, to an end user, a great UI will reflect his understanding of the tasks he needs to accomplish.
However, there is one argument you could make that would support DTs UI being closely modeled on the underlying mechanism. Such a UI does make the system more extensible by the end user and therefore more “powerful.” When designing for other engineers, that’s usually a good choice - they’re familiar with the underlying mechanism anyway and abstracting the UI would just feel constraining to them. So, you could argue that, yes, DT requires us to understand the underlying architecture and think like its programmers, but in the end it gives us more power. However, I’m not ready to concede that an abstracted UI following the mental model of most of its users isn’t a better choice, though. I believe that when users post to the forum that they wish it would follow mac-like conventions and suggest other similar mac apps, I think they are requesting the more abstracted model that these apps use. There are some concessions to these models in the UI already. So, right now DTs UI feels like a really uncomfortable tug-o-war between the two.
I’d have thought a better example of a photography-related program that forces you to peek under the hood is Photoshop. Applications like lightroom have interfaces that make some sense to a photographer; they use stops for exposure compensation etc. In contrast, I don’t think there is a useful intuitive analogy between the traditional photographic process to adding curves layers and changing the blending modes to control contrast in PS (of course one can come up with processes doing similar things, but PS does not attempt to model them, it just provides a set of tools and it is up to you to work out what each does).
But indeed in that case you pay the price of having to develop a new mental model in exchange for greater flexibility. On the other hand, in our case, how do I benefit from working with a program that doesn’t let me easily assign shortcuts to scripts (except through the keyboard and mouse preference pane, which is hardly convenient and makes me type the whole thing?) How do I benefit from the fact that if I switch view modes modes (or whatever they’re called) it forgets what I had selected? I could go on. I find the program itself indispensable (literally), but things like the ones I mentioned are annoying and just make it feel unfinished (sometimes).
I don’t really see how the UI is closely linked to any model. Maybe the applescript interface is, but then again it is in all programs (that support applescript). And arguments to the effect that it’s a powerful program and one must get used to it may be true in other cases but have nothing to do with what I, at least, perceive as problems in DT. Honestly, it’s a conceptually simple program (in the grand scheme of things–I am thinking of Mathematica, not Delicious Library or that kind of thing), and I don’t see what sort of complicated model might be underlying anything in its interface. From a user’s perspective, it’s just a bunch of folders with a fantastic support framework for importing, classifying, searching etc.
Having said all that, I’d much rather it keeps going the way it is (ie, improving the functionality, stability and robustness and not paying that much attention to interface details) than like some other software seems to be going (ie, impressive interface, not that much functionality that’s not directly supplied by the underlying OS, eg spotlight searching etc, explodes in your face if you put too much stuff in it in the case of databases, not open-ended enough, and so on and so forth).
There, that’s off my chest.
If you write scripts it is handy to read the online help chapter regarding these. And there you can read that it is relatively easy to assign keyboard shortcuts by setting these on the filename of the script using a few conventions we have developed.
I just typed “keyboard shortcuts” in the Help > Search menu and item #2 “Scripts and Third-party apps…” lists exactly what you need…