@MichaelZuschlag hits the nail on the head: there are no matching guidelines for metro, and at least I’ve never seen any (platform-wide) for any platform.
At first look, the intent of the UI formerly known as Metro is at odds dense UI.
A “dense” screen would have to be broken up into detail pages (see Navigation guidelines).
Your first screen would have to be broken down (roughly) into the following pages:
- a “quick search” for customers
- an “advanced search” with filter options
- a “Contact Details” page with the main details, and “preferences” and “Personal” stowed away under expandable sections
- an address list
- a Trip list
- address details
- Trip details
(plus pages for adding / editing these)
Fundamentally, the pages would be task-oriented (find someone, add a trip for them, fix an address), whereas “Dense” is data centric.
Making this transition in the implementation would be quite challenging – and getting users accustomed to “dense” interfaces to make the transition wouldn’t be easier. It stands to reason whether FKAMetro would even be a good choice.
However, you can integrate aspects of Metro, looking modern, reaping the familiarity of users with some FKAMetro concepts, and the “progress in UX” that stands behind it.
Things you can carry over, with some effort:
Less data per page. In your first example, e.g. moving the (editing of) trip lists and addresses to a separate page.
Rationale: Users have learnt – mainly through the internet – to use the “back” button. Breadcrumbs are quite common and can provide both context and extended navigation.
Flyouts can especially can be used to integrate secondary navigation, editing and confirmation
Format for presentation, edit on demand. Format your data to be read, and provide editing – ideally in-place – on demand; e.g. on mouse over, selection or similar.
You do need a consistent indicator what is editable (a faint icon, background color, etc.) However, get rid of the traditional “boxes” around all but the active field, as they are visually dominating over the actual context.
Rationale: this is my understanding of the “simplicity” of modern UI: Tone down window decoration and the “technical aspects” of the app so that content takes the spotlight.
Task-oriented Navigation. Bring the most common user activities to the front, and let the less common operations step back. “Dense” often has little if any explicit commands, but moving data to separate pages should free up your UI sufficiently. Check Command Patterns if you find something that fits.
Looks and details. Use Style Elements and Layout that is FKAMetro-inspired.
In general, I see a significant effort for potentially little return in terms of usability, error rate, etc. It would be interesting to take a “dense” app, transform it to become metro-ish, and see how users respond. Users might hate you for it, or, probably worst, “meh” at it.
“Dense” applications are often little more than database-bound form elements and data grids bound to tables or views; the frontend development for a “beautiful” application is likely higher. Developing similar generic mechanisms and controls is likely a separate challenge.
Casual vs. Business. Somewhat related to the “is it worth it?” question: I’ve argued here that Casual and Business use have some conflict – very roughly: casual relies on “not too wrong, at worst you can undo”, whereas business often requires to take responsibility for changes. The respective styles are sometimes at odds.
sorry for all the letters 🙂