User first impression

[asvae]

We want to make sure new users get good first impression.

For instance, introduction pages are not great: https://vuestic.dev/en/introduction/overview

But we want to investigate what works and what doesn't (use analytics/ask around) before we commit to specific solution.

• Take a look at alert page.

[kushich]

@asvae @zvenigorodskaia @xx13

My thoughts about this.

So, to impress user we have to develop a cute and informative documentation which won’t have both visual and component bugs. 
The reason why we have to focus on visual part of our documentation is that it’s based on vuestic itself and users can see the final result of project which they can create by using vuestic and its basic styles.

Pre-release tests


Pretty important part which affects on user’s first impression. Mostly because we promote our releases, so new user will be disappointed if he will find out that something broken and does’t work as expected.
 I think we must have a specific label like release blocker for issues from these tests which must be fixed before release. I know that we have automated tests, but manual tests are required as well.

Landing:


• check if we have all icons and images;
• check all links;
• check keyboard navigation;
• check how it looks on both desktop and mobile devices (all browsers from list of supported browsers :) )
;
• check menu on mobile devices.

Documentation (new):


• check if status badges are updated;

• check if new feature pages exist and covered by examples and translations;

• check if roadmap page has information about following release.

Documentation (per page):


• check keyboard navigation and focus collisions;

• check links and images;

• check workflow of each example.

Essential:


• try to install clean project using the installation page (each method);

• try to use new features there (I think it also allow us to check if CDN packages are updated as well).

Visual improvements:

1. We have to change current theme colors. They are so bad and look like default colors from paint palette (so bright and contrast). We had white-lavender theme for vuestic admin and it looked so cool (better than what we have right now). Also colors have to pass contrast tests.

2. We must have colors convention for examples:
   • 
 Minimum: theme palette + 1 or 2 hex colors.

   • 
 Maximum: develop colors palette (vuetify ref).

3. 
Improve description of each example.

4. 
Rebuild examples ( add more informative texts, try to adjust examples to real use cases). Would be good to have misc section with rich examples which will present real use cases of component in combination with other components (vuetify ref)
5. 
We must have accessibility section there user can find information about keyboard navigation on component (and maybe aria-attrs as well).
6. Thoughts: Some kind of report button would be cool in a right bottom corner of an example wrapper which will generate a bug report template and fill it by component name + example name data.

Conclusion:


We have to make a release where we won’t add any new features, but rework and improve existed functionality. We have to check if our key features work to prove our main theses why people should use vuestic. It's quite important right and will work perfectly in a pair with our releases promotion. Let’s focus on quality, not a quantity.

[asvae]

@kushich

regarding pre-release tests:

• "check if we have all icons and images" - maybe something like "nothing unusual found on mobile and desctop version after visual check"?
• "status badges are updated" - would be nice to know how do you check that.
• "check if new feature pages exist and covered by examples and translations" - that's going to be handled in scope of QA for new features, it would be nice to go through all pages and see nothing obvious is broken.
• "check keyboard navigation and focus collisions" - I wouldn't check that for each release, especially in docs, we can check demos though. Maybe we can create a section on how we should test demos?
• links check we definitely should automate, too much pain, there should be tools for that.
• "check workflow of each example" - what would that mean? interact with each example?
• "try to install clean project using the installation page (each method);
" - that's handled with #2651, testing manually is just too much pain.
• "try to use new features there" - can you elaborate?

regarding visual improvements:

• "Also colors have to pass contrast tests.
" - Should probably be handled by #2853
• "We must have colors convention for examples" - can you elaborate?
• "
Improve description of each example" - good for first iteration of the document, but later on we have to explain this in details.
• "We must have accessibility section there user can find information about keyboard navigation" - I generally agree, but curious how important is that?
• "Some kind of report button would be cool in a right bottom corner of an example wrapper which will generate a bug report template and fill it by component name + example name data." - great idea, let's move this to separate issue.

Thanks for you investigation, awesome work 🤗

[rustem-nasyrov]

Some kind of report button would be cool in a right bottom corner of an example wrapper which will generate a bug report template and fill it by component name + example name data.

https://github.com/epicmaxco/vuestic-ui/issues/1208

[asvae]

@kushich can we add this to notion page with release QA guide. - https://www.notion.so/epicmax/f3c7ff0a60bb46568ff1b2db55a58880

Any leftovers from this discussion move to other docs.

[asvae]

We can use colors from this page:

https://vuestic.dev/styles/colors#color-presets