This is a long discussion. For starters, this is a mobile driven solution, and like with almost anything in "mobile first" scenarios, there's a lot of voices attacking or defending the literal translation of these mobile solutions.
First of all, I'd strongly recommend you to read the why and how the floating label pattern was created, by his creator. As you will see, there were a lot of considerations to build this, and it was enhanced by other people after his first deployment. However, you'll see there's absolutely no mention of desktop.
Does this mean you shouldn't use this on desktop?
Well, I don't think it's that easy. Personally, I tend to translate mobile to desktop as much as possible, so maybe I'm biased, but I'm convinced that most people is used to mobile very day, and common desktop affordances are easily overriden by the mobile revolution. This, and the consideration of whether to spend more time(=money) on something that has no clear advantages or disadvantages, makes me consider many of the "mobile only solutions" as default and translated to desktop. And floating labels is one of those solutions I like to use in desktop.
Think about this: floating labels emerge as a solution for space restrictions on mobile screens. So you could logically say "hey, I've a lot more space on desktop", which is true. But... is that absolutely true? If I use a responsive design, most elements will resize and/or change placement based on a grid. When all is say and done, you'll notice that most of the times you will end with approximately the same sizes within elements (namely a form). Furthermore, if I have more real estate, does it mean that I have to use it for a form? Now, (take this with a pinch of salt because I work mostly on teh marketing side of things, but) FOR ME, the form filling is the final goal. I NEVER make a form field wider than 360px so it fits on most mobiles, and if I have space, I use it to convince the user to actually FILL THE FORM. So as you can see, in most cases space is not an issue for me and I can easily use floating labels on desktop when needed: it will always be the same no matter the screen size.
All the blabbing above is to tell you why I personally have no problems with floating labels, and use them or use static labels as the project needs it. But let's go to real world implementation. See below:
As you can see, most of the things Nielsen mentions on that article are overriden, and some visual cues are added for additional ease of use. Granted, there are some issues still, like using these labels as placeholders when fields are really complex, but that is a case by case consideration. To see the pros and cons, take a look to Floating Labels article by Brad Frost:
Float Label Pros
The main advantage of this pattern is that the user keeps the field’s context after they’ve focused and entered a value. This provides for a more accessible, less frustrating experience.
- Clean and scannable by default
This pattern allows for a clean inline label experience by default, and only becomes a little more cluttered once the user has filled things out.
It needs to be said: this pattern is sexy. You usually can’t say that about forms. It looks good and the animations are a nice subtle touch.
Float Label Cons
- Still doesn’t provide room for both label and placeholder
Because the label is occupying the same space as the placeholder, there’s no room for additional hinting.
The label becomes small and possibly hard to read, but at the same time it’s not as big a deal. Once the user has interacted with the input, the label becomes a reference rather than an instruction.
Based on the few demos I’ve seen, there’s the possibility of wrecking accessibility and semantics.
(...)Ultimately, I think this pattern is a great way to overcome a lot
of the shortcomings of inline labels. I can’t wait to see the concept
I think this is an element you should consider on a case by case basis, and depending on your needs. Additional tracking and research might be needed if doubtful, but I think it's a great solution nevertheless