Announcing The Swift.org Redesign Project

Swift Website
1

On behalf of the Swift Website Workgroup, I'm thrilled to announce the Swift.org Redesign Project!

This project aims to modernize the website's appearance, enhance the experience for all visitors, and better support the evolving needs of our community. The redesign will reflect the forward-thinking spirit of the Swift language while providing a more engaging and intuitive experience on the site.

We believe the best way of achieving this is by including the Swift community in every step of the process. To get started, we invite you to read the project brief below and share your feedback in this thread.

:information_source: This project runs in parallel with the The Swift Information Architecture Project which aims to design and implement a unified information architecture for content across the Swift project, including the content on Swift.org. This project is also inviting the Swift community to participate.

Introduction

The SWWG is embarking on a project to redesign the swift.org website. This initiative aims to modernize the websiteā€™s appearance, enhance user experience, and better support the evolving needs of our community. The redesign will reflect the forward-thinking spirit of the Swift language while providing a more engaging and intuitive experience for visitors.

Project Objectives

Modernization of Look and Feel: Update the websiteā€™s visual design to reflect modern patterns and best practices, incorporating more color, visual effects, and iconography.

Improved User Experience: Simplify navigation, declutter content, and enhance overall usability to ensure users can easily find the information they need.

Reusable Components: Develop a set of reusable design components to ensure consistency across the site and facilitate future updates.

PS: The new information architecture is a separate project that is running in parallel and whose completion isn't a pre-requesite for this project.

Project Scope

  • Conducting a quick audit of the current website to identify strengths, weaknesses, and areas for improvement.
  • Developing new visual design elements and a modernized layout.
  • Creating a library of reusable design components for consistent and efficient future updates.
  • Implementing the redesigned site and conducting thorough testing to ensure optimal performance and accessibility.

Redesign Goals and Objectives

Modernization of Look and Feel

  • Decluttering: Remove unnecessary elements and reduce text verbosity.
  • Enhanced Use of Color: Introduce a modern color palette to make the site visually richer.
  • Visual Effects: Incorporate subtle animations and transitions for a more engaging user experience.
  • Iconography & imagery: Utilize icons to improve visual communication and guide users through the site.
  • Responsive Design: Ensure the site looks and functions well on all devices, from desktops to mobile phones.

Improved User Experience

  • Simplified Navigation: Streamline the websiteā€™s menu and navigation structure to make it easier for users to find the information they need quickly.
    • Move some navigation menu link that donā€™t need to be omni-present throughout the site to the landing page (Tools or Packages for instance).
  • Decluttered Interface: Remove redundant or outdated elements to create a more focused and intuitive user interface.
    • Example: ā€œLearn more" and ā€œRead moreā€ buttons.
  • Enhanced Readability: Optimize typography, spacing, and content layout to improve readability and reduce eye strain.
    • Reduce the verbosity of text in the landing page.
  • Interactive Elements: Integrate interactive components such as accordions, tabs, and modal dialogs to present information in a user-friendly manner.
    • Case by case basis. Potential pages that could benefit from this include Install and Packages.

Creation of Reusable Components

  • Consistent: Develop a library of standardized design components (e.g., buttons, forms, headers) to ensure a cohesive look and feel across the site.
    • Use Sass to define a collection of single-use utility classes (see Tailwind).
    • Use said classes to create reusable component partials.
  • Modular: Implement a modular design approach that allows components to be reused and combined in various configurations for different pages and sections.
  • Scalable: Ensure that components are flexible and scalable to accommodate future content and functionality expansions without major redesign efforts.
  • Efficient Updates: Streamline the process for making site-wide updates by using reusable components, reducing the time and effort required for maintenance.
  • Documented: Provide documentation for design components whenever possible.
  • Cross-Platform Compatible: Design components to work seamlessly across different browsers and devices, ensuring a uniform experience for all visitors.
  • Customizable: Allow for easy customization of components to meet specific needs or preferences.
  • Performance-first: Optimize components for fast load times and efficient performance.
    • Through use of vector resources, image variants, lazy loading, etc.
  • Accessible: Design components to meet accessibility standards (e.g., WCAG 2.1) to ensure they are usable by individuals with disabilities, promoting inclusivity across the site.

Technical Requirements

We will continue using Jekyll and Sass for the swift.org website redesign. Our goal is to make the styling portable, ensuring that design elements can be easily reused or adapted when we migrate the site to Swift.

Project Timeline

Phase 1: Design and Prototyping

  • Create wireframes and mockups for the new website design.
  • Review and refine designs based on stakeholder feedback.
  • Deliverable: static mocks of the redesign.

Phase 2: Development

  • Develop reusable components and templates based on the latest version of the design.
  • Conduct basic internal testing.
  • Deliverable: a new mega-branch with the implemented layout and components.

Phase 3: Content Migration

  • Plan and execute the migration of any content that we agreed to migrate.
  • Update and optimize content as necessary to fit the new design and architecture.
  • Perform thorough testing to ensure all content is accurately transferred.
  • Deliverable: PRs onto the same branch/repository used for the design.

Phase 4: Testing and Optimization

  • Optimize site performance, accessibility, and cross-browser compatibility.
  • Implement final revisions based on testing results.

Phase 5: Preparation + Launch

  • Finalize PRs.
  • Obtain necessary approvals from all stakeholders before merge.
  • Consider deploying the new design in a new staging/preview URL (preview.swift.org)
  • Deliverable: New design merged.

Phase 6: Post-Launch

  • Monitor site performance, user feedback, SEO.
  • Address any post-launch issues promptly.
  • Plan for ongoing maintenance and future enhancements.

Roles and Responsibilities

Project Team

Stakeholders

  • SWWG
  • The Swift Core Team
  • Apple
  • The Swift community

Community Participation

Participation in the Swift.org redesign project is open to all members of the Swift community.

There are a variety of ways to get involved:

  • Following the project progress on GitHub and providing feedback on the linked issues.
  • Turning on the ā€˜Watching First Postā€™ notification of the Swift Website category in the Swift forums.
  • Getting assigned to issues and opening PRs against the new-layout branch. Check with the project team on the forums, GitHub issues, or Slack for more details.
34 Likes
2

Exciting news!

I am curious: was using Swift to build the website considered at all? It would have been a nice opportunity to show off Swift's capabilities as a more general programming language. But I understand that the desire to use more mature tooling may outweigh that.

9 Likes
3

It was considered, but we opted to leave it as a separate project as it can run in parallel.

4 Likes
4

Search? Please.

6 Likes
5

This is really exciting! I'm looking forward to it.

I don't know if this is worth its own thread, but one thing that I think is vital to promoting Swift on the website is including testimonials about Apple's extended use of Swift.

If people have heard of Swift, they probably know it as "Apple's App language", or something approximately like that. It's for apps, user-space stuff running on a local device.

It may surprise them to learn that things like Private Cloud Compute are built in Swift, or that any of Apple's other backend services are built using Swift.

Apple sold over a quarter billion devices in 2023. I'm sure that just about any service Apple runs operates on a massive scale, and it would bolster Swift's credibility if we mentioned that at the point where we're trying to convince people that Swift is a great server language.

Same with embedded Swift. It's not a secret - there was a WWDC talk which directly says "The Apple Secure Enclave processor uses Embedded Swift". If Embedded Swift is currently shipping on a quarter billion devices, that's huge and we should definitely let people know about that!

A lot of large embedded industries are looking for a C++ successor language (e.g. the defence industry). Rust, of course, looks like a strong contender, but I think Swift could also be a realistic option. Especially if they learn that it is already being deployed on such massive scale in security processors (of all things). That's enough for it to make a strong impression and get a deeper consideration.

I don't know if this is an Apple policy thing or if the current website design just doesn't prioritise testimonials. That's why I mention it here.

16 Likes
6

Very nice! Just wanted to point out this link points to Swift Information Architecture.

2 Likes
7

One thing that I think is currently missing from the website, is comprehensive documentation of the core libraries, including the standard library and foundation, as well as the C APIs which are transitively exposed as Swift functions and types therefrom.

That documentation is currently located on developer.apple.com rather than swift.org, and in my experience it is often incomplete. Some pages have no explanation of the API at all, some are missing vital information such as generic constraints, and often I find that the only way to figure things out is by directly browsing the source code. The source code is not always easy to navigate, especially for things that are not implemented in Swift, and we should do a better job of making the documentation readily accessible.

I would very much like to see something along the lines of swiftdoc.org integrated directly into swift.org, ideally with coverage for all APIs available through any of the core libraries, including re-exported C functions and types.

A programmer using Swift should be able to browse the documentation section on swift.org to find all the functions and types which are available through the core libraries, complete with the accompanying descriptions, examples, and related information.

20 Likes
8

+1 to the above. While a redesign could be a healthy step, a re-content is perhaps much more practical. An experienced Swift dev might know where to look, but the majority of the knowledge is still pretty obscured.

3 Likes
9

What you describe is the purpose of the Swift Information Architecture Project, which was also announced today and is running in parallel with the redesign project.

11 Likes
10

Thanks for bringing that to our attention. Itā€™s now updated.

11

I don't know if this is directly related to redesign but something that is missing for a long time is something similar to https://swiftfiddle.com on the website. A simple playground to easily play with swift, which would be specially helpful for newcomers that use Linux or Windows, which don't have a ready to use software like Xcode.

17 Likes
12

First, thank you for your feedback.

I think there are two separate issues you describe:

  1. Where the documentation is hosted / located
  2. The quality of the documentation itself

The first issue is part of what the Swift Information Architecture Project, which is running in parallel to the redesign project, will be working to address.

The second issue is important also. IMO, for general usage of an API, developers shouldn't need to inspect source code to figure out how the API works. But it is outside the scope of the information architecture project - the goal of the project is that when that documentation is written it has a well-defined place where it will appear.

I encourage you to read through the information architecture project brief and potentially become a participant in the project. Although the project is just ramping up, there will almost certainly be a working group focused on documentation.

4 Likes
13

To add a bit to Reda's reply, this was definitely considered. As you might imagine, this would also be a significant undertaking along the lines of the two projects that were just announced.

Some additional rationale was that the website redesign and a unified information architecture are public-facing changes that will provide direct improvements for the entire Swift community.

Using Swift to build the website remains a goal, but replacing how the site is generated would have much less impact, with possibly no observable change, in improving the site for users. With that in mind, the website workgroup decided to give the projects that were just announced a higher priority.

7 Likes
14

Nice idea. Another feature that I would love to see on the swift.org website is an official swift playground similar to Google Go or Rust official website where people especially newbies can try out the language without

7 Likes
15

Thank you for the suggestions! We would love to add a playground to Swift.org, and it's something we've discussed and considered for a while as we've heard this feedback before as well.

There are some technical challenges to figure out first though, and I personally think it's unlikely that we would have time for this within the scope of this redesign project. I will bring it up to the rest of the SWWG though to see what we can do about it.

2 Likes
16

While I understand that this is something both sides need to work on, I think it would be nice to extend the packages site with Swift Package Index integration and get package data from there.
While being a community project, SPI is already mentioned on the official Swift site and I would love to see it as the ā€žofficialā€œ SPM index integrated with the Swift site.
Imo Swift is in need of an official package index sooner or later and why reinvent the wheel when SPI is already there? Of course this would also need to be accepted from the SPI side but Iā€˜d see this as a nice step forward.

3 Likes
17

Hello, I noticed that the brief is missing a mention of on page technical SEO in the page and components. Please be sure to include a check for that. One of the success metrics of the project I suggest to be a higher google lighthouse score than current site which is already quite high at the time of this writing of 97 for performance so maybe a goal should be to not go lower. The SEO score is however 77 so that leaves some room for improvement. https://pagespeed.web.dev/analysis/https-swift-org/oi1y5owl9a?form_factor=mobile

Let me know if there is any help I can provide on the SEO side.

1 Like
18

Thank you for bringing this up. It is not mentioned in the brief since SEO will have to involve the Information Architecture project as well, or perhaps be its own project once both make enough progress. We'd be happy to reach out if/when that effort starts!

19

Thanks for thinking about the project in this way. :heart:

We are already providing the data for the Packages page and sub-pages on Swift.org. We run a process that updates the packages on a monthly basis with all data being provided via the Swift Package Index.

The process of curating the Community Showcase is also managed by me through my participation in the Swift Website Workgroup, but all the data also comes via the Swift Package Index.

Of course, there is always the possibility for closer integrations with Swift.org and we are always open to possibilities there.

3 Likes