An analogy (?):
Think of the tap on your kitchen sink. "Open tap" produces water and the normal destination for that water is "down the drain". If you want to "filter" the water before it goes to the normal destination, you "pipe" it to the filter. Technically, the output of "open tap" becomes the input of "filter" and the output of "filter" goes to the normal destination (down the drain). That would be
"open tap" | "filter"
Maybe you want to filter it in many ways:
"open tap" | "filter1" | "filter2"
If, you'd rather have the water go into a pitcher (than down the drain), you "redirect" the output.
"open tap" | "filter" > "pitcher"
At this point it's over; the water has reached it's destination. If you want do to more (filter further, or change the location of the water) you must start over with an action that produces water, perhaps
"pour water out of pitcher" | "filter3" > "glass"
A bit more technically, the "stdin" and "stdout" streams (programming terms) start with a process that produces data (stdout) which normally is written to the console. You can make things happen to that data (before it reaches its destination) with pipes. Pipes send the stdout of one process to the stdin of another process (not changing the ultimate destination). If you want to change the destination, redirect. Redirection is to a device (file, display, clipboard, ..., not to a process) and after redirection, the input/output chain is finished..
So, your second example is odd in two ways.
1. "DIR > CON:" is, at best, redundant. That's where DIR's output goes by default.
2. After "DIR > CON:" the output has been disposed of. There is no output to send to VIEW.
I may be wrong, but I don't think it makes sense to follow a redirection with a pipe.
I hope all that makes some sense.