Swift Website Workgroup Meeting Notes - 6th September 2022

kaishin · October 12, 2022, 6:52pm

Attendees

@mishal_shah gave an update about the ongoing PR preview setup.
@kaishin suggested setting up a preview on his fork in the meantime. @mishal_shah sees no issues with that approach.

content-improvements branch created by @mishal_shah.
First PR opened by @kaishin.
@mishal_shah and @kaishin discussed the open PR. Agreed on not waiting for the Swift version metadata to merge the PR.

Community announcement posed by @alexandersandberg.
Content changes pitched on the forums by @alexandersandberg.
@alexandersandberg summarized the feedback we got in the content thread. An interactive playground was brought up more than once. Showing code as well. Expanding on use cases. Case studies, for instance Amazon’s Prime video’s use of Swift on the server etc.
@alexandersandberg pointed everyone to the content tree he shared on the forums and asked for further feedback. In particular, about the new install page that was extracted from Getting Started and Downloads.
@alexandersandberg pointed out that we need more content for the getting started page. We need to ask for help within the core team perhaps or someone else in the SWWG.
@kaishin pitched the idea of using a tabbed interface or a dropdown to select the OS.

@james_dempsey brought up the possibility that users might come with different goals and/or expectations. Building a mobile app vs. building a server-side app, etc. Guiding them might be key.
@kaishin mentioned that there could be additional use cases like scripting and making command line interfaces.
@mishal_shah raised the question of whether we need code on the getting started page at all. We can focus on installing Swift and provide links to various examples.
@alexandersandberg agreed that the purpose of getting started is to guide users, not teach them how to write Swift.
@james_dempsey pointed out that currently Getting Started points visitors to Linux/Windows tooling. We can point users to Xcode as well (Apple Developer Portal).
@mishal_shah pitched the idea of detecting the visitor’s OS and pick a default downloads/install instructions based on it.
@kaishin asked if we are open to having cookies to remember users’ choices. @alexandersandberg pointed out that we can use local storage as we do today for themes.

@mishal_shah mentioned that the download section needs to be reworked to use this metadata since the current approach might not be scalable.
@alexandersandberg proposed planning for the future of the download page in the content improvement branch. @mishal_shah volunteered to discuss the download page with anyone interested.
@alexandersandberg highlighted the importance of putting forward the latest version in the download page, since that’s what most visitor care about.
@mishal_shah invited everyone to think about how we can make it easy for people to know which releases apply to which platform, including the last supported version in a deprecated OS version.

@James_Dempsey mentioned that people might think the Xcode version they have is outdated when they visit the site and see a newer patch version than the one that ships with Xcode. Perhaps group the releases by minor release, for example 5.7.x.
@mishal_shah clarified that Linux releases are still available via toolchain, but can’t be used to submit apps to the App Store.

@mishal_shah shared some Swift API early thoughts. For instance adding the metadata in a YAML file and exposing it as a global variable in Jekyll.
@mishal_shah proposed having a URL that can serve JSON or YAML contain metadata about all releases (including nightlies) and download URLs. This will be particularly useful for people writing automation and installer scripts.
@alexandersandberg mentioned that this work can be done in parallel to the content/design updates. We can promote it at a later stage.
@mishal_shah agreed on doing a soft launch to gather feedback.
@mishal_shah will start a thread outlining the plan and goals.
@james_dempsey asked about the inclusion of Linux flavors in the API. @mishal_shah confirmed that we can include such data in the API as well.
@james_dempsey suggested adding which version is accepted in the App Store. @mishal_shah pointed out that a notice banner might be enough.