The choice was to either just use a WYSIWYG field and hope no user would change things drastically and break the layout, or to just put everything in code and not allow a user to edit it at all. Neither seemed like good solutions as they couldn't provide both consistent structure and usability.
Different levels of customizability and layout can be achieved through things like views, blocks or panels, but views is a bit of a workaround, blocks repeat the same issue and for any complex layout, panels quickly become unwieldy both in the configuration and in markup.
Two modules aim to aid in this area though: Bean and Fieldable Panels Panes. Both allow for the creation of fieldable entities that can easily be placed around a site, filling in any area where the creation of a new content type doesn't quite make sense.
Bean
Bean, which stands for Block Entities Aren't Nodes, allows you to create block types that contain fields. These block types are very similar to content types, except populating them creates a new Bean instead of a new node, and they can then be placed anywhere on the site just like a block. This means you can very easily allow a user to fill out information in a structured and expected way anywhere on your site. After using Bean for the first time I was really impressed and found that it solved a lot of the issues I had with out-of-the-box Drupal.
The creation process couldn't be easier either. To create a new block type, you just name it and start adding fields. The fields available to you are the same as the ones available to your content types, meaning you can really go crazy with the utility of these blocks.
Bean also plays nice with other modules. The display of your Block Types can be customized like the display of a node, including laying them out through Panelizer. Since in the end you just are creating a block, you can place them via any means you would normally place a block. This all means Bean is very flexible and powerful.
Fieldable Panels Panes
I was shown Fieldable Panels Panes (FPP) much more recently. After hearing what the module did, my reaction was âOh, Bean for panels!â, and that is pretty much what it is. If you're familiar with Bean, you'll be right at home here. The main difference comes in what is produced; Bean gives you blocks while FPP gives you a panels pane.
Creating an FPP is, like a Bean, very similar to creating a new content type and node. You again simply name your new type and then add your fields. The FPP UI for doing this does make it feel a little different as types and the panels you create are all in one place, missing the distinction of 'Structure' and 'Content' that both Beans and nodes have, but the principal is the same in all cases. FPP also has the interesting option of limiting a newly created pane to only being placed once on the whole site, which allows for more verbose intention, but can be a bit annoying when a design changes.
As should be expected, FPP utilizes the same fields as nodes and Beans, and plays nicely with panel related modules. In fact, FPP is nicely integrated with panels, allowing you to create new panes from the panel content menus. Once created, an FPP pane can be placed just like any other pane, including being put into a mini-panel to act as a block.
Comparison
Both FPP and Bean solve the same problem and do so in pretty much the same way, giving you fieldable entities that can be placed around a site. This overlap means that you'll only be using one of these modules on any given site, which begs for a comparison of the two. The problem with doing that though, is that the strengths and weaknesses of each of these modules aren't so much in their own features, but in the features/utilities of the modules they are using; blocks vs. panels. You'll end up choosing to use Bean or FPP not so much depending on the merit of one module over the other, but depending on your preference for laying out a site. If you swear by panels and use it on all of your sites, FPP is probably best for you. However, if you detest panels and would rather place things as blocks through the use of something like Context, you'll probably want to check out Bean.
Of course, both modules are pretty flexible. Bean works fine on a panels site as you can still place blocks easily in panels and, as mentioned, Beans themselves can be panelized. You could similarly place all your FPPs into mini-panels and place them around like blocks, although you might get some strange looks for doing so.
All of this being said though, I would give the edge to Bean as it's probably the more versatile module. This is mainly due to the fact that blocks are a part of Drupal already whereas panels aren't. Bean simply adds to stock Drupal whereas FPP adds to Panels. FPP has the edge if a site has been built using panels due to its integration with the module, but Bean still performs well in a panelized layout. Panels is prepared to work with blocks as they're standard and therefore is prepared to work with Beans. Using something that already exists on every site is a big advantage of Bean and is probably why it is the more popular of the two.