I'm finally biting the bullet and rebuilding all my websites in @rapidweaver. I used Apple's iWeb until they stopped supporting it about a decade ago. After much agonizing, I went with Sandvox, which was similar but better on several counts. But now they're out of business.
Learning any new app takes time, this thread will be "notes to self" for the next site I build because things that take a week to figure out can often be explained in a minute or two, so hopefully others will find this thread useful.
A few things about my web presence: 1. I do as little coding as possible because I don't build sites for a living. My solution must have a WYSIWYG interface. 2. I have several sites, so any solution that charges by the site and month won't work for me.
The newest version of RapidWeaver does a great job with responsive web design on a range of devices, automatically serving up images scaled to those devices without me having to create all those image sizes for each one, like other web-building apps require. A huge timesaver.
I strongly considered Wordpress but the learning curve was just too steep to get the look & feel I wanted in a reasonable amount of time. But the Stacks on which Rapidweaver sites are built remind me a lot of the new Wordpress Gutenberg systems of blocks.
Wordpress is the world's #1 site builder & has a huge following so it should last a long time. But the Wordpress ecosystem is a notorious hacker target since it's so big. My RapidWeaver sites are built on my Mac and hosted by my webhost. And the RapidWeaver community is big.
To get started with @rapidweaver: 1. Buy the app at realmacsoftware.com. Stacks are the essential building blocks, which you can get from @YourHeadSupport. Next you'll need a robust framework of components. The two top candidates are Foundry & Foundation by @weaversspace.
I started with Foundry but then went to Foundation once I discovered they play well with Hoefler web fonts, which I've used for years. weavers.space has a bunch of other great stacks built on Foundation, and a robust user community.
I initially bought Font Pro with the intention of using it with Foundry, but couldn't get my web fonts working so decided to get Foundation to replace Foundry hoping they would play nice together, both being part of the weavers.space ecosystem.
I struggled for a couple more days getting my web fonts to work. Finally, I asked myself whether it might be because I hadn't published the site yet. To that point, I'd just been building the basics on my Mac. So I published. Nothing happened at first. But then I noticed this at the bottom of the Hoefler Font Family Setup box: "In order to preview your fonts, you must add "127.0.0.1" to your domain list in Hoefler (RW7 only)". I'm on RW8.7 but thought I'd give it a try. It worked! Not sure which fixed it, as I did one right after the other and it might have taken a minute for the publishing to trigger something in my Hoefler account, but I don't really care since it’s working now.
weavers.space developer @joeworkman has lots of tutorial videos which are really helpful but it took me awhile to realize he's developing stuff so fast that many of the videos are from previous versions. For example, he talks a lot about swatches but I couldn't find anything that said "swatch" in Site Styles, which is the nerve center of Foundation. That's because since the video was posted, swatches have matured into Font & Text, General, and Component swatches. Once I realized that, things got much easier.
I have Font & Text swatches for my text style, link style, and heading styles from h1 to h6. I have General swatches for background colors and for margins. You can use swatches as a "class," which you can apply to almost any stack on a page by tagging it with the class name.
You can also apply swatches to a long list of stack types. Doing this means you don't need to tag them with the class, but it affects all such objects on the page. As a result, I do mostly class swatches. I have two Component swatches: Top Bar Styles & Menu Styles.
Speaking of Top Bar & Menus, I'm rebuilding all my sites with a black background (more on that later). Some devices are small enough that the menu wraps to more than one line, and the leftover space was a light grey, which looks bad.
I worked for a couple days trying dozens of options before figuring out a hack. At the top of Site Styles, there are Component Colors and Text Colors. The latter is easy, but I don't know what the Component Colors do because they haven't shown up on anything I'm doing yet.
Exasperated, I did a screen shot of the grey leftover wrapped menu area and drug it around the screen, trying to see if it matched anything. One color is called light grey & looked like a perfect match. I changed it to black, and that solved the problem.
Knowing all that stuff now, I can probably set up my next site in a few minutes instead of a couple weeks. Hope this helps someone else. In any case, the rest of this thread will be about my new site design system.
I'm doing black background design for several reasons. In 1984, Macs brought computers out of the DOS black-screen world into the light of black letters on a white background, like real life. But now black-screen design is cool, including on apple.com.
Black-screen design also uses less energy, which might not be much on one computer, but is a big deal on many. And since http://originalgreen.org is about green building and living, it makes good sense. Plus, I use a lot of black in other places as well, so it's consistent.
I started studying the best new sites in late November, and noticed several things: With responsive design being essential today so you don't get dinged by the search engines, designs with many small pics are out, as is clutter, including the page-top banner.
The top of my page has a simple SVG (scalable vector graphic) logo on the left and a menu bar on the right. Below that is a big, beautiful image. I save a 4K (3840 x 2160) version of my best work for presentations & a 1920 x 1080 for tweets and other social media posts. The great thing about RapidWeaver is that I can use the 4K version of my images and RW will automatically serve up the right sizes to each device, including Retina devices. And by using 4K versions, they'll still be good when sites get to 3840 pixels wide (mine are 1280 now).
Below the title image is my page title and text. @joeworkman has moved Foundation to markdown text, which I've never worked with before. I really like it because you can switch between text & header styles with just basic keystrokes all in the same text box using no HTML.
On long blog posts, I'll definitely intersperse images with text throughout the post as I've always done, but those images will all be full-width cinema-proportion 16:9 images so they're big and beautiful.
Something else I noticed about the best new design is that sidebars are mostly out today. The best sites take the clutter that would have been in a sidebar and put it in a box at the bottom of the page, so the user experience is just beautiful images & text.
My footer box includes a Google site search bar, links to where you can buy my book, email links on speaking & ideas to write about, a subscribe box, social share buttons & follow buttons, a Facebook Comments box on most pages & a sitemap of the 1st & 2nd tier tabs.
originalgreen.org has hundreds of pages, and the Facebook Comments box requires the URL of the page it's on. I'm building the new site at dev.originalgreen.org but when the site goes live, I'll have to fix the comments box on every page.
Also, all the inter-site links I'm building right now will have to be re-done once the site goes live. So I have a radical thought: I don't currently sell anything direct from any of my sites, so I'm wondering about just building the new site on originalgreen.org.
Another great thing about RapidWeaver is that I can make URLs pretty much whatever I want, including the identical URL of the old page. So there's no need for redirects, which are a huge task on a big site.
Building a site live at the permanent URL means that if someone comes to a new part of the site, they'll only see the part that's currently built, but if they have a link to an old page, then they can still see it right up until the day the page is rebuilt.
Does anyone know why this strategy wouldn't work? I feel like I'm standing at a point of no return on this. What am I missing? Develop on dev.originalgreen.org or right on originalgreen.org? All thoughts appreciated; if I'm gonna do this, I need to start now.