You can read all about it in Quincy's announcement.
There are many ways to contribute. Check out the CurriculumExpansion repository. The projects are listed as issues where you can join in on the discussion about each one. Projects with a help wanted tag are unclaimed, so leave a comment in that issue and mention @scissorsneedfoodtoo if you'd like to work on one. We'll also need help reviewing projects that have been broken down into steps and submitted as pull requests.
Yes, the goal is to move to a single column layout that resembles an actual code editor. You can read more about it in freeCodeCamp Redesign: Command Line Chic. Since the editor will take up the majority of the screen, things like the HTML preview, console output, and the current test you're working on will appear contextually between lines of code. Here's a rough example of what that might look like: 
I claimed an open project. How should I build the prototype?
Use your favorite online code editor and post a link in your project's issue when you're finished. CodePen, Glitch, CodeSandbox, and Repl.it are a few popular platforms.
No, contributors should not use any sort of framework or library while building one of the new curriculum projects. The exception is projects where it's required like "Learn React by Building Flappy Bird". Otherwise, stick to plain ol' HTML, CSS, and JavaScript. (Note that this doesn't apply to users, who are free to use whatever frameworks/libraries they want for the Front End Libraries Certification projects.)
We want all of this to work even when people’s browsers are offline, so we won’t have the benefit of running a server or making calls to an API. Instead, contributors should create their own return statements, error messages, and output to mock the functionality of those services. We’ll use regular expressions to test user input. That said, feel free to use these services while working on your prototype – it’ll be easier to see how your project should run.
Start breaking it down step-by-step like this. Since the new UI will include multiple file support, break your project down into separate HTML, CSS, and JS files. Write your test descriptions in the file around the area users will be focused on during that step. For example, if the user has to add a property named text to an object, write your test description in the JS file near the line the user will be focused on. Your test descriptions should be short, without a lot of explainer text. Every step will test exactly one thing, so don't worry about edge cases. When you are finished, submit a pull request to the CurriculumExpansion repo.
After you break your project down into steps and submit it as a pull request, reviewers will go through the code and test descriptions in each file. If reviewers notice something that can be changed, they'll leave a comment with some suggestions. Once your project and test descriptions look good, we'll merge your PR!
My pull request was merged and my project is part of the new curriculum. Is there anything else I can do?
Absolutely. Please consider working on another unclaimed project or helping us review other submitted projects. And stick around -- eventually we'll start writing the actual tests that will run in the browser, so we could use your help implementing those.