Like the database-specific inbox, they aren’t “global” in nature, so I’m not sure why they are under Globals.
This was put in place because users have wanted a way to access such things like the Tags for all open databases.
OK, I can see the value in added it to Globals. But why remove them from the databases themselves? I find they have a great value when they are right in the database, acting as almost a special kind of smart group.
1 Like
Likely to avoid redundancy, since they’re already accessible in the Global sections.
…like how groups are redundantly accessible in both the sidebar and list view now? 
Redundancy isn’t always a bad thing.
2 Likes
I can’t upvote your comment enough. I can appreciate the globals in the sidebar. But not showing the local inbox and tags within each database is a flaw. The obvious solution is to show them in both locations. It would be a good use of redundancy.
3 Likes
Here’s my argument for having them in both:
- tags in sidebar: good for when you are editing/managing your tags in bulk
- tags in database view: good for organizing navigating content that’s been tagged
I’d settle for dt3 to just stop crashing over…and…over…rebuild/ignore?..i’ll just wait a year to use it i guess. dtpo2 is so memory intensive at this point it clogs my brand new mac to use it, and dt3 crashes constantly…aghhh
Well, it’s still a beta. Did you send us the crash logs?
1 Like
I have to say that I didn’t even give much thought to the new inbox setup until reading this post. I think it looks much nicer than the old way, but as I’m using it I’m finding it less efficient (but that could just be due to my way of working). Using @t_hayash’s desk analogy, my setup has me feeling like I have a bunch of inboxes in the waiting room, but the desks for those inboxes are down the hall in different rooms, making it a little unwieldy to ultimately get things where they need to go.
What would be very efficient (again, for me - I recognize we all have different workflows) would be if the database inboxes were mirrored in 2 places - in the current list of all inboxes, and within each respective database.
Yup, I agree. It feels like we have to walk down the hall and then go to a room where all the inboxes are. Then walk a few steps more to open a door for the inbox you are looking for. (that’s how it feels)
Mirroring within their respective databases could be an option.
1 Like
I actually use the multiple inboxes. Here’s how and why.
The global inbox is the initial collection point. I can dump everything into there.
Periodically I’ll go through the global inbox and triage things into the correct database, by dragging them into the appropriate database inbox. For example, I have personal and work databases, to keep the things separate.
Deciding “personal or work?” is a nice easy mental task, I can skim through a bunch of global inbox entries quickly and drag them to the right place — without considering or even seeing the individual categories or tags within the destination database.
Then later on when stuff has built up, I’ll pick a single database’s inbox and go through things in more detail, tagging and filing.
If I tried to do the entire filing process at once for each item, I’d get sidetracked.
The secondary reason to have multiple databases and inboxes is that I don’t have all databases on all devices. So, for example, I can take a document out of long term storage on my Mac, and drop it into an inbox which replicates to my mobile phone (but not have it get lost in any clutter in the global inbox). Then on the phone later on, I’ll know right where to find it.
The problem isn’t having multiple inboxes. There absolutely should be a global inbox and individual inboxes for each database, for exactly the reasons @meta described. The problem is not showing the individual inboxes (and tags) in the databases to which they belong, placing them only in the sidebar.
OK, so basically the thing you disagree with is that DEVONthink 3 puts all the inboxes together, rather than placing each one under its parent database like DEVONthink 2?
It took me a while to get used to that too, but now I prefer it, because it’s easier to handle the initial triage of incoming data when all the inboxes are in the same place without having to scroll or expand/contract things.
As I recall, dropping something on a database icon in DT2 would put the item in the inbox of that database. So it wasn’t too bad to do your initial triage, so long as you understood that behavior and knew to collapse all your database icons by default so you could see them all next to each other. But I think what the developers are going for with the new design is making the intended workflow flow naturally from the user interface, with no knowledge necessary. You encounter the master inbox, notice all the other inboxes are there alongside it, and it is quick and natural to then shuffle things between inboxes. It’s also easier to go to a non-global inbox and shuffle things back elsewhere if you make a mistake, than it would be with the DT2 design.
…Also, the “all the inboxes in one place” convention will probably be more familiar to users, because that’s how Apple Mail handles it.
…Also, the “all the inboxes in one place” convention will probably be more familiar to users, because that’s how Apple Mail handles it.
That was indeed a consideration of a familiar paradigm. 
That’s true for Apple Mail (OS), but in iOS you can both see all the inboxes together, and also drill down to one account and see that inbox in context with the rest of that account. This is what I’d be looking for.
Having the default location of inboxes and tags be the sidebar is fine, but it would be also be helpful/logical — at least for some of us — to have the option show a database’s inbox and tags within the database itself as well.
2 Likes
This is exactly how I process inforamtion.