search

cdevents / cdevents.dev

https://cdevents.dev
Apache License 2.0
2 stars 5 forks source link

Introductory landing page, versioning #22

Closed tdcox closed 1 year ago

tdcox commented 1 year ago

Signed-off-by: Terry Cox terry@bootstrap.je

netlify[bot] commented 1 year ago

Deploy Preview for cdevents ready!

Name Link
Latest commit 09dd7f894dededb0861cc98fb4e32c20e56eacaf
Latest deploy log https://app.netlify.com/sites/cdevents/deploys/637fa4e44e4f0500090b314c
Deploy Preview https://deploy-preview-22--cdevents.netlify.app
Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site settings.

tdcox commented 1 year ago

Cleaned up...

e-backmark-ericsson commented 1 year ago

I looked at the proposal a bit together with Mattias L today and here is some feedback:

afrittoli commented 1 year ago

The new font is definitely an improvement, thank you! I still feel a bit lost in front of a wall of text though, even more so on a mobile where the text takes more vertical space, e.g.

image

I think the first scrolling page should not contain extra text so that the scroll arrow is displayed:

image image

I think it would be nice to use some visual tool to diversify more the content, like the three columns with icons, or tiles with a title or else, I'm open to suggestions. We could break the text with a diagram for instance?

It looks like the colour schema was changed - is the change related to accessibility? If so, are there other colours that would fit instead of the ones used in the PR? Until now the look and feel was built around the colour from the project logo,

tdcox commented 1 year ago

From what I can see, the reactive defaults in Docsy are set up based around a 1920x1080 baseline display. It steps down as you get to a number of intermediate display sizes for different devices, and this triggers different reactive behaviour, including first miniturising the top menu (which causes the Releases menu to be hidden) and then eventually hiding the whole menu bar in the hamburger menu. The hidden Releases menu is either an intentional feature, or a Docsy bug. We could try reporting as such?

I'm not seeing any obvious way to limit the text width at max resolution. This all appears to get calculated dynamically. We probably wouldn't want to reduce this in any case, since it would give up problems rendering the tables in the specification and make the white paper hard to read.

tdcox commented 1 year ago

@afrittoli The importance of the two example images you show above is the difference in visual hinting and how that impacts behaviour. In the original example, it looks to a new reader as if this is an empty landing page and that the first action for the reader should be to click the 'Get Started' button. This jumps you into technical documentation, unprepared. A very observant reader might press the down arrow, or scroll, but having to place arrows on a page to tell people how to read them is a fundamental failure of UI design, which places graphic design sensibilities above usability.

In the revised design, we are informing the reader of a shortcut to jump out of sequence to get straight to the docs, but we are also showing that there is more to consume on this page by hinting that the text continues by scrolling. Note that for most users, scrolling is a one-handed guesture, but button-pressing requires shifting grip or using the other hand.

The visual language that you are hinting at, has a different purpose. When you are looking at marketing pages for mature products, they are using a lot of graphical images to reinforce a brand image to a target market segment, by subliminal association. The customer already knows what the product is, and the intent is to reinforce them feeling good about the product during their visit.

You have a very different issue. You need to attract early adopters who have a very specific problem that could be solved if this product was built. When they hit the site, you have less than 20 seconds to get them to read the first 100 words and hook their attention enough to get them to invest 2-3 minutes to explore further and establsh if this addresses their problem. If you fail to convince them that this solves an immediate problem in their field, they will move on. The only people who will get to the point of reading the spec is that tiny subset who have the problem that CDEvents mitigates.

At this very early start-up stage, it is easy to fall for the vanity approach of trying to replicate a glossy sales brochure, but it's too early for that. Instead, you must apply the Continuous Delivery methodology and create experiments that engage with the early adoptors who have this problem badly enough to be willing to work with you to solve it. Your web page is an elevator pitch, not a sales brochure.

tdcox commented 1 year ago

The colour scheme has been adjusted to start to address accessibility issues. The blue/green combo in the logo creates severe contrast issues, so we need to use more complementary accent colours to work around this.

e-backmark-ericsson commented 1 year ago

From what I can see, the reactive defaults in Docsy are set up based around a 1920x1080 baseline display. It steps down as you get to a number of intermediate display sizes for different devices, and this triggers different reactive behaviour, including first miniturising the top menu (which causes the Releases menu to be hidden) and then eventually hiding the whole menu bar in the hamburger menu. The hidden Releases menu is either an intentional feature, or a Docsy bug. We could try reporting as such?

Yes, if the disappeared Releases menu seems to be a Docsy bug I believe it should be reported.

I'm not seeing any obvious way to limit the text width at max resolution. This all appears to get calculated dynamically. We probably wouldn't want to reduce this in any case, since it would give up problems rendering the tables in the specification and make the white paper hard to read. Ok. I hoped it was possible to set different widths (either in words, characters or pixels) for specific paragraphs/sections without affecting the whole site. If that is not possible then so be it.

e-backmark-ericsson commented 1 year ago

@afrittoli The importance of the two example images you show above is the difference in visual hinting and how that impacts behaviour. In the original example, it looks to a new reader as if this is an empty landing page and that the first action for the reader should be to click the 'Get Started' button. This jumps you into technical documentation, unprepared. A very observant reader might press the down arrow, or scroll, but having to place arrows on a page to tell people how to read them is a fundamental failure of UI design, which places graphic design sensibilities above usability.

I agree to that. And I then also think that we should not have the Docs or GitHub link buttons provided that early on the page. The documentation link is already in the top menu, to readers looking for that could easily find it without having it where "Read the Docs" is now. And the GitHub link could be moved to the top menu as well I think.

tdcox commented 1 year ago

Yes, if the disappeared Releases menu seems to be a Docsy bug I believe it should be reported.

I have raised an issue on the Docsy repo.

tdcox commented 1 year ago

And I then also think that we should not have the Docs or GitHub link buttons provided that early on the page. The documentation link is already in the top menu, to readers looking for that could easily find it without having it where "Read the Docs" is now. And the GitHub link could be moved to the top menu as well I think.

Agreed. I have updated and it looks better without the buttons at the top. The GitHub link is in the Community page, which I have also fixed in this PR. We need to add a contribution-guidelines.md file in the root of the spec repo (Docsy default location).