I miss Rapidweaver style themes in Elements

[Flash]

I miss Rapidweaver style themes. The way they work. I understand they have limitations. But they were so much faster to build a website with. If I could ask for a feature request I would, but I seem to remember it wasn’t possible. I just miss the ease of use.

[ben]

what is it that you miss from the old style themes?

We now have projects and templates that give you a lot more flexibility, have you tried using those? (Dan is also building more projects as I type this).

I understand that the old style themes felt quick and easy to use, but they lock you in to a single design and layout, making it very difficult to change anything without starting from scratch.

[MichaelDroste]

Initially missed them also… the ability to click through and see what your site would look like in x theme - then y theme and so on… often times would cycle through themes and then come back to original hahaha

When the store first started - i expected a plethora of new themes - never came…

Trying switching themes and/or changing colors

Might help….

Best
Mike

[Flash]

Fair question. I miss knowing that the design someone has put together is what mine will look like. I am not a designer. I never adopted the blocks or stacks methods. I miss being able to take a theme, click it on, add body copy, add page/meta info, and hit publish.

EDIT: and BTW be able to use the styled text editor a like a word processor. Rapidweaver might have been a bit sloppy code but the foundation for fixing that has already been addressed in Elements

This (Elements) method is clearly more flexible. If your a designer and have time or skill or patience to play with it.

[Flash]

I might be off base here, and some of this may simply show my lack of experience with Elements.

I haven’t invested a huge amount of time into Elements yet, although I have invested money. Before I invest the much larger amount of time required to build my site, there is one part of the Elements workflow I am still trying to gain confidence in.

Once a full page design is built, how dependable are Templates, Globals and the component system as the foundation of a large website?

I’m not talking about the CMS. I understand that the CMS is still developing and has a lot of room to grow. I’m talking about the core of Elements itself.

For a small site, an occasional odd behavior or workaround may not be a major problem. On a site with hundreds of pages and a lot of shared pieces, the underlying system has to be rock solid. If I build the site correctly around Globals, Templates, Components and shared styling, I need to know that changing something six months later isn’t going to create surprises across hundreds of pages.

There is some encouraging evidence.

Eric’s recent thread about rebuilding a 1,300+ page website is particularly interesting to me:

85 Pages Down. 1,300+ to Go. Here's what I've learned about Elements

I’ve been rebuilding our 1,300+ page website in Elements, and the first 85 pages are now complete. Working on a project of this size has been a great way to experience the framework beyond a typical brochure site, and overall I’ve been extremely impressed. I’m convinced RapidWeaver Elements is the right choice for us moving forward. It’s fast, stable, intuitive, and a pleasure to work with. One feature I’ve particularly enjoyed is the ability to move components seamlessly between the page layou…

When I asked how Elements was handling the project, he said performance had been “amazingly fast.” That is exactly the kind of real-world experience I’m looking for. His project is not identical to mine because much of the eventual content will be generated through RW CMS, but seeing Elements remain responsive with a substantial project is encouraging.

At the same time, I still run across discussions like these:

Globals and how they are intended to work across pages:

Global header and footer

I have to ask here, because there is no documentation for these components. Are they supposed to appear on every page? Is there something that has to be set to get them to appear on every page? If not, how do I copy them to other pages? Although the components are copyable (sorry), they won’t paste on another page.

Copying and pasting components between pages and projects:

Copy and Paste

How do I copy component(s) from one page in my project to another page in my project I’m choosing the component from one of my pages. On Edit menu I select ‘copy’. Then I select the page where I’d like to copy the component. I then select Edit menu but the paste option is grayed out. I’ve tried Ctrl C and Ctrl V but no luck Link to my project: elementsapp://downloadDocument/nXe6f1uOXIqV Thanks

Neither of those threads proves there is something fundamentally wrong with Elements. In fact, they may demonstrate the opposite problem: users sometimes don’t understand the intended workflow, discover a different way of doing something, or need someone to explain how the pieces are designed to work together.

That gets very close to the source of my own hesitation.

I previously asked about using Elements for a site in the 300–600 page range, and Dan was very fair in saying that making Elements more suitable for large document sites was something on the list to tackle, although he couldn’t say when or in what form:

Large website--Elements Native or Elements CMS?

This is an open question for anyone who might have experience using Elements on a medium to large website. I am asking how this has worked for you. My parameters: The bulk of the content (300 pages) is 400–2000 words. About 40 pages are 5000 words. These are all going to be interlinked pretty heavily. I would like to have a single photo on each page. The reason I ask about Elements rather than the CMS is that Elements has the page database for me to reference in the drop-down to build the li…

My project has continued to grow since then. I’m now looking at roughly 600 pages, with a great deal of internal linking and a lot of shared structure. That changes the consequences of getting the architecture wrong at the beginning.

So when I occasionally see discussions involving copy/paste, drag and drop, Templates, Globals or other behaviors producing unexpected results, I pay attention. Sometimes there is an answer. Sometimes there is a workaround. Sometimes the discussion simply seems to stop.

From the outside, it can be difficult to tell whether I am seeing an isolated bug, an incorrect workflow, a documentation issue, or a limitation I need to design around.

And that may actually point to the bigger issue for me:

I don’t think I fully understand the intended Elements workflow yet.

I know sometimes the best way to learn is simply to jump in and start building. I’m sure I will learn a great deal that way. But I suspect I’m not the only person looking at Elements and wondering how all of these pieces are intended to work together once a project becomes large.

A number of people have asked for a start-to-finish video showing a website being built in Elements. As far as I know, most of the material available demonstrates individual pieces of the system.

The pieces aren’t really my problem.

It’s the process of putting them together into a dependable, repeatable system that I’m struggling to see.

I’m a systems guy. SOPs—Standard Operating Procedures—are how I’ve spent much of my working life. I build cookie cutters. I figure out a dependable process, document it, teach it, and then repeat it. That is how I’ve taught thousands of people to become good cooks, chefs and operators.

That is what I’m trying to understand with Elements:

What is the Elements “cookie cutter” for building and maintaining a large site correctly?

For example:

1. Build the overall Theme and global styling.

2. Build the primary page structures.

3. Convert the pieces that need site-wide control into Globals.

4. Create Templates from the completed page structures.

5. Build new pages from those Templates.

6. Make structural changes through Globals and styling rather than page-by-page editing.

7. Maintain hundreds of pages without gradually introducing inconsistencies.

Maybe that is exactly how Elements is intended to be used. Maybe I have part of it wrong.

That is the documentation or video I would really like to see: take a fictional 20- or 30-page site and show the complete process of building it correctly from beginning to end. Not just how to use a Global, Template, Component or Theme individually. Show how they fit together into a system that you would be comfortable using if that same project eventually became 500 pages.

If that workflow is clear and the core systems are dependable, I suspect most of my concern disappears.

[thominator (Thom Hogan)]

A lot to parse here. Let’s start with the general: no, I don’t think Elements is well suited to hundred page+ sites. I’m assuming here you mean that these are all somehow directly accessible in the traditional manner (e.g. menu). Elements is also not well-suited to completely changing a site design after the fact, and the more pages there are, the bigger that problem will be. Yes, you can change fonts and colors easily, but real change of design means you’re dealing with all the Components, which are not in the Theme settings.

On the other hand, the CMS does provide a way of dealing with tons of pages. However, this is going to assume that you don’t have a lot of different styles for those pages, as otherwise you just end up in the same problem as dedicated pages. For instance, I have one site I’m playing with that uses CMS for a blog section, an articles section, and a review section, all handled differently. The good news there is that this opens up use of the Online Editor to populate all those things.

Now to a couple of things. I’ll begin with your 7 steps at the end. #1 doesn’t need to be #1. I’d say the primary problem is site (page) structure. Without that, the rest isn’t going to work. With a CMS-driven site, your order would go more like:

1. Build structure (pages, folders, CMS)
   1. Pages first, but…
   2. CMS-driven bits each need an index page and an individual post page (call it “the templates”), and they also need appropriate folder areas for content
2. Create globals (menus, footers, etc.)
   1. Put them into every page in the structure
   2. Put each CMS component into the appropriate places in the structure (blog for blog, articles for articles, etc.)
3. Populate the CMS (preferably via online editor).
4. Work the Theme and colors to style as desired.

As for Globals. Let me give an example of how that works (I’ll use menus as an example, but same applies to pretty much any Global).

1. Create a page.
2. Put a Container at the top.
3. Design your menu system in that Container.
4. Convert that to a Global and give it a name, such as Site Menu.
5. Site Menu is now a Component in the Globals section. Drag it out to every page in the site at the top.
6. If you make a change on any page to Site Menu, that reflects across the entire site. If for some reason you want a page to be different, you can decouple the Site Menu on that page from being a Global and make changes directly that don’t impact the rest of the site. But that would be rare.

Finally, you bring up the “copy” issue I’ve been complaining about since day one. “Copy” and “Drag” in Elements don’t exactly follow macOS guidelines. Some things work, some things don’t. You just have to learn the behaviors that do work and use them.