Right, yeah, systems people use eight hours a day are quite different from 'e-commerce solutions' and 'corporate blogs' and have very different UX-demands. Whe

Right, yeah, systems people use eight hours a day are quite different from 'e-commerce solutions' and 'corporate blogs' and have very different UX-demands. When you're in front of an application that much layout is more or less unimportant as long as it can easily be interpreted by someone who has been sitting there for a year or more. This typically means that a newcomer will feel an immediate discomfort at layout and program flows, there's just too much and much of it is impossible to interpret without initial assistance. This also means that when you change something it has to be run by pretty much every user first, or the one percent users that is actually really annoyed will pull in the rest and everyone will hate your revamp of their workplace. Typically you can add to the interface though, and that's how long-lived 'enterprise' software gets cluttered views that are incomprehensible to newcomers. If you enter this segment of development you need to understand that the users are like Unix greybeards, it's just that their version of urxvt and zsh and vim is a graphical interface to business processes. They'll get mad when things aren't like they've been for decades, and they'll try to have you guillotined if you force 'whitespace' and 'just enough information per view for the purpose I, master developer, think it should have'.