Let me know what you feel we’re missing, as we’re keen to make sure we’re ahead of similar Mac apps!
IMO (Not all that humble 
)
Anchor
Dropdown Menu
(Generic) Audio Player
(Generic) Video Player
Those were what I thought were absolute for core components. I wasn’t sure what some of the specific components are that @WeaverPixel called out in his post, so can’t really comment on those.
I will have some more specific and general comments tomorrow.
1 Like
It is a long list, but as you have stated some of these can probably be made up from core elements. This list only contains what Blocs refers to as BRICS, which are the finegrained building blocks. They also have BLOCS which are more complex components built up from either Brics or custom made.
Text Link - this is a really powerful component as there are a wide range of actions it can perform, coupled with a wide range of targets. This component would negate the need for an anchor as it allows you to accomplish the same result, but without having to specifically create a component. It can link to any element on you page so you can jump to that element. This is actually a feature that is also available in some other component such as a button.
Dropdown
Cookie Consent
Form (text field, text area, option select, checkbox, radio button, and recaptcha)
Alert
Accordian
Tabbed Content
Modal
List
Markdown
Block Quote
I have bolded the ones I think are core to being able to successfully build a modern website, even though all of these are fundamental to a good website builder. There are more than the ones shown I distilled it down.
If I was only allowed to pick one from this list it would be the TEXT LINK because it would allow me to get my site to 95% complete. With the cookie consent and contact form being the only things preventing it from being complete.
1 Like
So I was thinking through a lot of this. And there are a lot of things I want also. Then I started thinking some more. What is the balance between RM shipping a product that has potential and a product that has an adequate feature set but is solid, trustworthy and stable?
What are the bare minimum requirements for a WYSIWYG website design software application? What features must it allow a person to create and include in a modern brochure, informational website?
Core Functionalities
-
Visual Editor:
-
Drag-and-drop functionality for adding and positioning elements.
-
Real-time preview of website appearance.
-
-
Basic Layout Tools:
-
Support for creating responsive layouts (e.g., grids, flexbox support).
-
Predefined templates for common layouts (header, footer, sidebar, full-width sections).
-
-
Element Library:
-
Basic elements like text boxes, images, buttons, and videos.
-
Forms (contact forms, subscription forms).
-
GDPR Note: Ensure any form includes:
-
Explicit consent checkboxes for users agreeing to data collection (e.g., “I consent to the storage of my data for [specific purpose].”).
-
Information on data usage, with links to a privacy policy.
-
Media Management:
-
Ability to upload, manage, and place images and videos.
-
Basic image editing (cropping, resizing, alt-text for accessibility).
-
-
Styling Tools:
-
Customizable fonts, colors, and sizes.
-
Background settings (color, gradient, or image).
-
Predefined style options or themes.
-
Website Features
-
Navigation System:
-
Ability to create menus (horizontal and vertical).
-
Links for navigation (internal pages, external websites, and anchor links).
-
-
Responsive Design:
-
Auto-adapt layouts for desktop, tablet, and mobile views.
-
Preview tools for different screen sizes.
-
-
Basic SEO Features:
-
Ability to add meta tags (title, description).
-
Support for custom URLs for individual pages.
-
Alt attributes for images.
-
GDPR Note: Ensure SEO and analytics do not collect user data without consent (e.g., anonymize IP addresses in analytics integrations).
Publishing Tools:
-
One-click publishing to a web server or export as HTML files.
-
Basic hosting options or integration with hosting providers.
GDPR Note: Hosting options should clarify compliance with GDPR, particularly if servers are outside the EU. Ensure data transfer agreements or safeguards are in place.
Contact and Social Integration:
-
Embeddable maps (e.g., Google Maps).
-
Social media sharing buttons.
-
Email and phone links.
GDPR Note:
-
Cookie consent is needed for embedded third-party services (e.g., Google Maps or social media widgets) that may track users.
-
Provide users with an opt-out mechanism for cookies and third-party tracking.
User Support and Accessibility
-
Accessibility Compliance:
- Warnings or tools to ensure WCAG compliance (e.g., text contrast checker).
-
Undo/Redo Functionality:
- To fix mistakes without restarting.
-
User Guidance:
- Tooltips, tutorials, or a basic help section.
Optional but Highly Recommended for Modern Design
-
GDPR-Compliant Cookie Management:
-
Include a built-in cookie banner or management system that:
-
Allows users to opt-in to specific types of cookies (e.g., necessary, analytics, marketing).
-
Provides a clear explanation of cookie usage and links to the privacy policy.
-
-
-
Animation and Effects: Simple transitions or hover effects.
-
Integration with Analytics:
-
Embed Google Analytics or similar tools while ensuring GDPR compliance:
-
Anonymize IP addresses by default.
-
Disable tracking until users provide consent.
-
Offer an opt-out link or mechanism.
-
-
-
Custom Code Support: Ability to add custom HTML, CSS, or JavaScript for advanced users.GDPR Note: Warn users to ensure any custom code is compliant with GDPR when handling user data.
Privacy and GDPR Compliance Summary
To meet GDPR requirements, the application must support:
-
Clear consent mechanisms for data collection via forms, cookies, and third-party integrations.
-
Anonymization tools for any data collected.
-
Options for users to opt-out or withdraw consent easily.
-
Prebuilt GDPR-compliant components like cookie banners, privacy policy templates, and consent checkboxes for forms.
So, please go with this list what you want.
1 Like
My Thoughts are My Own!!
Elements, as currently marketed, is touted as a WYSIWYG Static Web Page Design Software.
I don’t consider a CMS to be a static web page(s), nor do I think a blog is a static web page(s). I will get back to these.
Its stock components that are included should be the foundational building blocks necessary in order to create a STATIC web page. It currently has many of those. It is missing others, based on my and other folks observations. However, there have been requests for some components by people (myself included) that aren’t really the core building blocks. For instance, a footer. The included components can be used to create a footer for one’s site, then made a global and used throughout the site. Footer done. If a component can be easily and readily created by use of the core components, I do not think it needs to be included, at least at this time.
I believe that the best use of the developers time would be to focus on core components, bug fixes and work on solutions for some of the other pain points that many of us have found during the closed Beta. I truly want to see a Rock Solid app for the public beta. As I have said in earlier posts, this is the first website design software since GoLive 6 that I like, that I have been able to successfully recreate my existing website and that I have been productive with. After a few hours of playing with Elements and spending time with Tailwind CSS Docs I am able to create the pages I need to create to modernize and re-do my current website.
CMS & Blogs - I am not convinced that Elements is the right tool to use for a CMS or Blog other than for laying out the design of the site. Both CMS and Blogs require significant server side stuff that really isn’t provided with Elements. (I know I am oversimplifying it here, and I know a well versed developer will probably be able to create those type of sites - which shows how powerful Elements really is)
Here is to the longterm success of Elements 
Anywho, those are my thoughts for the day.
2 Likes
Bonjour,
Est t’il possible d’obtenir le thème de la page : RapidWeaver Elements
je le trouve, simple, beau avec le petit menu flottant en haut à droite.
Bon dimanche
Jean-Marc
Static websites are increasingly outdated in today’s digital world. They lack flexibility, requiring manual updates for any changes, which is time-consuming and impractical for businesses needing frequent updates. They offer no personalization, resulting in a poor user experience, and struggle with SEO due to the absence of dynamic content. Additionally, maintenance requires technical expertise, making them inefficient compared to dynamic websites with CMS platforms. While suitable for simple use cases, static sites fail to meet modern demands for functionality, scalability, and competitiveness.
However, a blog can be a simple way to overcome a large part of this issue if articles can be uploaded directly without publishing through software, with display handled server-side. This approach is not as complex as a full CMS and remains relatively straightforward.
2 Likes
You seem to think that there is only one type of Web site that should exist. I’d argue differently.
Dynamic sites open up vulnerabilities for sites that are primary fixed information only, and then have additional issues with restoring, when necessary. That’s particularly true for me, as I travel Internationally a lot, and my ability to be online is often compromised. We don’t all have IT staffs at our beck and call. Reverting to last night’s backed up static site can be done in a moment, fixing a dynamic site that’s been hacked—and it will be hacked in my area of work—takes longer online access I don’t always have.
I compete against a number of dynamic sites, and I believe I do so well.
That said, what most of us are looking for is a mix of dynamic (CMS) and static. Many of my pages can be fully static. A few could benefit from CMS. However, I certainly don’t want to be designing part of my sites in one product and the rest in another. I would also point out that the original Rapidweaver lives in this same place. A lot of folk added dynamic through stacks and foundations, and designed in RW. Having Elements be “just static” long term would be indeed be going backwards.
I’ve run sites with pretty much everything from the simplest static builder to the most complex (and expensive) deep/wide database driven dynamic site. There really isn’t a good tool that bridges that, and I believe Elements can be that.
From a visitor’s perspective, I could make an argument that over 90% of the content on both static and dynamic websites is essentially the same. With proper planning and setup, a static website can be nearly indistinguishable from one rendered dynamically via a database. In fact, static websites often outperform their dynamic counterparts in terms of speed and security.
However, dynamic content has its place—for instance, features like user commenting, which can generate indexable content that boosts SEO. Beyond this, I struggle to identify other reasons why small to moderately sized websites couldn’t thrive as static sites. In many cases, they might even benefit from being static.
One feature I’d find invaluable is the ability to securely add pages and media to a static website without needing to open Elements. This functionality could be awesome—so long as it synchronized seamlessly with the Elements Project file when opened, eliminating risks like overlapping or deleted data.
No, I don’t think that only one type of site should exist. In fact, I am for everyone’s freedom and I don’t judge, this doesn’t prevent me from being pragmatic. I totally agree with your remarks. My intervention was in the context of the future of Elements. I help three small associations to maintain their static site because it only informs: the two or three annual events, the general assembly, the end-of-year meal, no cookies, no tracking, no race for referencing and ranking… so no need for dynamic content. However, for another small association, the need to be able to put up-to-date content online directly without going through/depending on a third party was a necessity (without a CMS like Wordpress that is far too heavy). I am for the hybrid solution that you present, that’s why I gave the example of a blog that is not supported by a CMS like Wordpress but by a simple mechanism for uploading files then managed on the server side. In fact, we forget that in 2000 we were already doing this without CMS thanks to CGI or PHP scripts. The CMS “website creation and management software” fully installed on the server has become the automatic reference today but it does not have my approval for many reasons, most of which are personal to me, others more general like those you raise with relevance.
All this brings up another remark in the “automatism” of the answers, if “CMS” is part of it, “Cloud” also. Here too I am rather very reserved because I remain faithful to the joke that circulated for a while on the Net: “the cloud is just someone else’s hard drive.” I indicated in the preamble that freedom is very important to me, it was to prepare in conclusion the fact that “captivity” leads me to move away from its sources such as expensive subscriptions that do not allow me to be free (I’m not against subscription in general) or services that when we decide to no longer use them force us to start all over again because our data is no longer usable (like blog articles). This is a pitfall that I think must be avoided so that Elements can take off when the solid base that has been talked about a lot lately is actually reached.