Suggestions from the website review

[roll]

Homepage

• Peter/Ethan: Word “simple” -> minimal, lightweight?
• Ethan: Everything with underline (like titles) should link somewhere
• Peter/Ethan: Cards should link
• Steve: Big screenshot of one programme. Maybe better to have cards there too
• Keith: (potentially) diagram to see how specs link. Peter: add this on the “Explore the standard” page.
• Peter: testimonials (blog posts) as Adoption. More engaging that number of logos (some could remain)
• Phil: show how users can immediately pull a Data Package into their environment (like R). A bit like a usage section. Jesper: maybe under software: a carousel or tabs per language, have animated gif on how it is used.
• Phil: mention FAIR. Peter: if above fold, have the last sentence of intro be “It is a data definition language (DDL) and data API that facilitates FAIR data exchange.”
• Ethan: have a more friendly landing for GitHub page.
• Peter: branding? Sara: maybe recolour the logo a bit. Peter/Phil: I like the darker blue better than the logo blue. 🙂
• Ethan: Documentation section at bottom seems like an afterthought
• Peter: Indicate version, cf dropdown cf. Bootstrap https://getbootstrap.com/ (keeping older versions online? => Peter: I guess the CHANGELOG is sufficient from v2.0 onwards)
• Ethan: Borrowing from the bootstrap website, "Get Started" could become "Read the docs" – sentence case and clear that it goes to the documentation ;)

Guides

• Pierre: Why a Guides page, if there is a Guides menu item?
• Evgeny: overview pages can likely be removed. Peter: or integrated as first section in the menu section. Evgeny: agree
• Peter: make FAIR a header in the Introduction page. Kyle: agree
• Phil: have single header “Standard” with Specifications, Governance, Changelog. Peter: agree. Evgeny: agree.
• Phil: have a “Getting started” or an “Overview” page. Peter: or a “Rationale” page that explains header by header why you would want to use Data Package (not reinventing the wheel)
• Peter: also mention how Data Package links to other standards or what alternatives there are. Steve: NSF LTER’s EML data packages, etc
• Peter: how are we going to collaborate on rewriting some pages. Ethan: start iterating on an outline (section and page names for the left navigation sidebar) before tackling the content of each page?
• Peter: specifications have grown organically and would need a single editor to make them more consistent in how things are phrased.
• Move out of the table-specific components – we go beyond tabular data. Let’s abstract more. Peter: please keep the scope a bit on tabular data (that’s already a huge scope), which is a point of recognition for potential users. But it can be mentioned that we can branch out to non-tabular data.
• All the documentation on the website will be moved to the specs repo: https://github.com/frictionlessdata/specs
• Peter: have a develop branch to bundle all changes for an upcoming versioned release, while typos and rewrites (not-version specific) can be published directly to the main branch (and have the main website updated) -> Design development model regarding branching/deployments #945

https://docs.google.com/document/d/1chRTxCTo-_HIfCdGv5ApmR2PObk_ISf1Vt-vRTBbMFM/edit

[roll]

Peter/Ethan: Word “simple” -> minimal, lightweight?

Changed to simple here - https://github.com/frictionlessdata/datapackage/pull/75/files. Personally, I don't have any opinion about using or not using any of these words

[peterdesmet]

Simple is used for almost all specifications in the v1: https://specs.frictionlessdata.io/ I think we can keep it that way. Let's hope that with enough documentation and a getting started guide, users also perceive it as simple.

[roll]

Ethan: Documentation section at bottom seems like an afterthought

TBH the only function of this "Documentation" section at the bottom is when there use scrolls completely down they has some useful links to go like a footer (so it does not look like a dead-end):