Website Design Update

[moul]

We aim to update the design of our main website. The current design could benefit from a more minimal, simple, and efficient approach in terms of space and speed. We invite you to propose solutions and be considered to take ownership of this project component.

---

We're looking for someone to:

1. Migrate the design: The new design should be more similar to suckless.org. It should be super minimal, simple, straightforward, clean in hierarchy, and efficient in space. The emphasis should be on the content rather than flashy visuals.
2. Optimize the HTML/CSS/JS: The website's code should be minimal and optimized for speed.
3. QA everything: This includes the site itself and the func helpers. We want to ensure that everything is working as expected and providing a good user experience.
4. Switch to a non-monospace font: By default, the website should use a non-monospace font. However, code blocks should still use a monospace font.

---

Before starting, we'd like you to give feedback on these proposed changes and define your plan to tackle this project. Once we agree on the plan, you can proceed with the redesign.

[amritkumarj]

Sounds like a great idea! We've created a preliminary design to showcase our vision for the website and would love the opportunity to contribute to its development. Thanks!

[alexiscolin]

Hey team, @moul, @gfanton , @zivkovicmilos, @leohhhn

To bootstrap this FE/design project, we should consider the following elements:

Given that gnoweb is a web tool used by developers during the smart-contract creation workflow (localhost focused), but also by general users to view the render of all indexed realms (kind of smart contract browsing):

1. Browser Compatibility

• One of the most important question: what are the minimum versions of each browser we aim to target (IE, Edge, Safari, etc.)?
• If we want to be universal, targeting a broad set of browsers makes sense. However, even if the website is straightforward, some parts could be improved by using modern CSS or JS features.
• Consider using a tool like Babel for JavaScript transpiling and Autoprefixer for CSS to ensure compatibility with older browser versions.
• Images: Ensure compatibility with modern image formats like WebP while providing fallbacks for older browsers. Use responsive images with srcset and sizes.

2. Accessibility:

• Do we want to be 100% compliant with ARIA and A11y recommendations? (This would be beneficial for this project, in my opinion.). This involves keyboard navigation, color contrast checks, descriptive content, semantic html, text alternative, clean and valid html/Css etc.
• If yes, do we want to implement accessibility tests, with predefined standard (WCAG 2.1 guidelines would be great)?

3. SEO

• Do we want the website to be fully indexed?
• If yes, we might want to create dynamic meta properties (allowing smart-contract creators to customize realm metadata).
• If not, we need a strategy to create default, automated meta titles, descriptions, canonical tags, etc.
• What is our strategy for handling sitemap and robots.txt files?
• Should we include Open Graph tags and Twitter cards for better social media sharing?
• Might be great to use structured data (such as jsonlp) to help search engines understand our content better
• Performance and Mobile Optimization is a good consideration. Having a website in mobil first could help improving the ranking as many search engine bots are testing website in mobile first today. It's also a good practice (keeping in mind our users may be not on mobile)

4. Security

• What level of security and which security measures should we implement (XSS, CSRF, etc.) to address threats that could arise from form components and other components ?
• How will we handle authentication and authorization if needed?
• Should we use Content Security Policy (CSP) headers to mitigate XSS attacks? Maybe it's already the case (this question is far beyond this front-end dev issue but good to keep in mind if it's not already the case).

5. Third-Party Scripts

• Are we going to use third-party scripts in addition to Simple Analytics, etc.? I guess we should avoid as much as we can (for security and performance mattersà but it's still a question

6. Front-End Tooling

• We should implement a front-end workflow with a bundler, a linter, and testing tools. For example:
  • Bundler: Use a modern bundler like Vite, Webpack, or Parcel to bundle and minify our assets efficiently, enabling features like code splitting and hot module replacement. The one we should use would be related to the browser compatibility.
  • Linter: Implement ESLint for JavaScript and Stylelint for CSS to ensure code quality and consistency across the codebase. We will need a standard to follow.
  • Formatter: Use Prettier for automatic code formatting to maintain a consistent style. We will need a standard to follow.
  • Testing: Integrate a testing framework such as Jest or Mocha for unit tests, and tools like Cypress or Playwright for end-to-end tests.
  • Browser Compatibility Tools: Do we want to use tools like Browserslist to manage and query the list of target browsers and check the render for all of them. May be too much for this website though.
  • Build Performance: Optimize build performance by using caching strategies and efficient plugins. Is it something we can do?

7. Code Structure

• How are we going to set up our CSS and JS code?
• For CSS, using a clear semantic architecture (BEM, SMACSS, Atomic, etc.) would help us maintain consistency in the long term, avoid DRY violations, and address web performance issues while improving codebase maintainability.
• We need a good and agnostic naming convention.
• Another question is the use of a CSS preprocessor, which may be unnecessary for a tool that aims to be simple and straightforward.
• How will we structure our components? (e.g., Atomic Design, Component-based architecture)
• Should we use Typescript to get a more robust and organized code? How to organize and document code to ensure readability and maintainability? Might be a good idea anyway.
• Should we use tools for documentation? (e.g., Storybook for UI components, JSDoc for code documentation)

8. Performance

• How will we test and optimize the performance of the website? Do we want a webperf budget (score)?
• What tools and metrics will we use to ensure the site loads quickly and efficiently? I would recommend Lighthouse, WebPageTest to start, they can also be added to the CI.
• How will we implement lazy loading and code splitting to improve load times if it's something we want to add (depending on browser compatibility)
• Minification and Compression need to be kept in mind. Minify CSS, JavaScript, and HTML files using tools like UglifyJS and cssnano, and enable Gzip or Brotli compression on the server.
• Even if the website content is mostly made by texts, Image Optimization for modern formats like WebP, optimize images with tools like ImageOptim, and implement responsive images using srcset and sizes could also help.
• A good Font Loading strategy should be used. Using default OS font might improve the loading speed, while a swapping strategy in the CSS to ensure text remains visible during webfont load could be another idea.
• Implement effective caching strategies with HTTP headers for static assets and leverage service workers for offline caching.

9. Developer Experience

• Could wee add the front-end workflow within gnodev? To ensure rapid feedback loops during development (e.g., hot module replacement, fast build times)?

I will take care of addressing these questions and providing solutions with a plan next week. I have many ideas for these. But some are important such as the browser compatibility. I would recommend a good balance to target JS/CSS feature used by more than 95~96% of users. Also maybe targeting IE might be too much mut maybe we want to target more and even 100%.
Anyway, this is just an initial list of considerations, a task list that I'm sharing with everyone. Let's collaborate and refine these points together to ensure our project is robust, user-friendly, and maintainable.

Feel free to discuss further.