What i'm looking to achieve
I am looking at options for reducing the number of stories we snapshot and test in Chromatic (currently nearing 400). We use storybook for our design system and also for visual testing with Chromatic.
Currently our stories are roughly structured as a story for each set of states / major variation of a component. For example our button has:
Sizes - sm, m, l, responsive
Colours - primary, secondary, danger, etc
Layouts - left-icon, right-icon
Playground - a story containing single button where you can interact with all the various inputs. Playground stories are already excluded from Chromatic.
I was thinking of adding a "visual test" story to each component which would have every variation of the button on a single canvas and then only include the "visual test" stories in the chromatic tests. In the button example this would reduce button snapshots from 3 to 1, and we have other components with way more variations than this.
The best solution I found for this is to create a doc page, i really liked the option of using MDX to compose a page that includes multiple stories
<Story id="some-component--some-name" />
<Story id="some-component--some-other-name" />
MDX Docs
The Problem
So far I cannot find anyway to make chromatic take a snapshot of a doc or pure doc page. I have tried making docs the default view in my storybook, and even hiding the canvas tab in my storybook altogether, but it seems Chromatic must parse and render the stories with their own config.
The Question
Is there a way to force chromatic to take snapshots of doc pages, or even better of "pure documentation" MDX pages (as described in the MDX docs)
Alternatively if anyone has any other suggestions about creating a story composed of other stories, that could also be a solution to my problem.
Currently the only alternative I see is to duplicate stories, which isn't ideal.
You can disable all snapshots at ./storybook/preview.js then you enable it for single stories. I just don't know how to achieve that using MDX (which is my case as well)
Update: I guess the following does the trick for MDX (if you're disabling all from preview.js then pass { disableSnapshot: false })
<Story name="StoryName" args={{
chromatic: { disableSnapshot: true }
}}>...</Story>
``
Ref: https://www.chromatic.com/docs/ignoring-elements#ignore-stories
In the end the solution to this was an add-on called Variants. You can ignore all stories from Chromatic by default and only take snapshots of stories that use the Varitants add-on to display every variant on a single page.
storybook-addon-variants
Related
Does anyone know how I should handle aria-labels on link labels that repeat dozens of time on a page? My website accessibility checker tool keeps flagging these elements as using the same link text for these labels and they require unique aria-labels. Problem is, all of the links go to the same generic pages and am not sure how to make the aria-labels specific enough.
Has anyone dealt with anything like this before and how did you handle it? I imagine I'd need a JS solution to inject aria-labels, but before I invest in a JS resource doing this for me does anyone know how I can make these specific enough to pass the checker but not confuse screen readers?
Screenshot of category labels for each article
In this case, it is correct to hide all duplicate links except for the first element that contains these labels
You force people with disabilities to navigate through all the same links using keyboard navigation, this is also bad for a screen reader
1.) Hide any duplicate labels from your screen reader
aria-hidden="true"
2.) Hide any duplicate labels from keyboard navigation
tabindex="-1"
Note! don't forget to leave one unique link! You can also hide everything and add them to context under elements or above elements. When I say hide, I mean the above methods.
It's easy to check for accessibility, close your eyes and imagine you click on a tab and hear (in a screen reader) a re-link through every two elements! This is annoying isn't it?
There is no need for aria-labels and what you are doing is not an accessibility fail. You have to bear in mind the automated accessibility checkers are dumb (and in this case quite possibly wrong) and are only there to offer guidance on common accessibility fails.
The main reason you are seeing this is that the accessibility checker thinks that this is text like "read more" that is not descriptive of the end-point. It should pick up the fact that the end-point is the same but it obviously does not.
Using the same link text for links that go to the same page is encouraged:
It is a best practice for links with the same destination to have
consistent descriptions (and this is a requirement per Success
Criterion 3.2.4 for pages in a set). It is also a best practice for
links with different purposes and destinations to have different
descriptions.
Source: https://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-refs.html
Also one of the checks for success criterion 3.2.4 - Consistent Identification is:
Check that this associated text is identical for each user interface
component with the same function.
Source: https://www.w3.org/WAI/WCAG21/Techniques/general/G197.html
Assuming your articles are marked-up correctly a screen reader user could skip between headings (<h2>s for example) in order to not hear the same category links. This is one of the primary ways a screen reader user will navigate a page (via headings).
For this reason the categories should be AFTER the heading in the HTML so that they are read out after the heading.
You could place the heading visually after the tags using techniques similar to those in this answer I gave. This would be acceptable for "logical tab order" in my opinion so you wouldn't fail there.
Your only other option would be to use aria-hidden="true" and tabindex="-1" on your category links to hide them from screen reader users and take them out of the tab order. If you did this you would need to ensure a categories list is available at the side of the page.
Personally I would go with the first option as the categories information is useful to screen reader users, the fact the links repeat themselves over and over if I search by links would indicate they are categories to me when using a screen reader anyway.
I have a list of pages that have to appear in different places of my Plone. If I use an internal link, I see an HTML link in the page but instead of that I would like to see the embedded content of the linked page.
I've tried to install some link plugins (Smart Link, vs.alias...) but I'm not able to find the solution.
I'm using Plone 4.3.
I don't know any Plone Plugin, which satisfy your requirement.
A long time ago i wrote this small js to show internal links in a popup using Plone's prepOverlay.
In this case you can put a popup custom CSS class on the internal link with TinyMCE.
It simply shows the content area of the given URL.
$(function(){
jq('a.popup').prepOverlay({
subtype:'ajax',
urlmatch:'$',urlreplace:' #content > *'
});
});
I guess this is a good starting point for your own implementation.
You could think of a criterion like location, contenttype, etc., to distinct, which articles should be picked (in worst case use collective.flag), then fetch them with a collection, to give you the links as a resultlist, and set its view to all_content, a nice feature, introduced in the Plone-4 series.
I would like the member/visitor of my website to be able to create article about themselves. Instead of using the normal way which is "Content - Add Custom Article" and fill up everything in the lengthy way. I prefer to let them do it in a multiple steps way (just like check-out process in Amazon).
i would like to create a multiple steps form that consists of 3 steps to create a content page. The first step needs to be able to allow users to upload multiple images in 1 shot and display the thumbnails in a gallery below it. The gallery needs to allow re-arrangement(re-ordering), cropping and resizing.
The layout is something like this
#
Step 1 of 3 - Tell us about your detail
Name :
Your Photos :
Next Step
#
Please give some suggestion on the modules that I can use to achieve this kind of design.
Thanks!
This might be useful.
Media gallery module also might be useful though it is still in beta.
As for the multistep process for saving articles, it seems to be pretty straightforward way of storing the information as user goes from one step to another and saving the entity when the final step is complete.
As far as I understand, an App can post into a User's Timeline.
My question is, how much can you customase/style this post?
I believe you can, at least, add a custom image and links. Can you also add HTML elements and CSS?
for example, nikeplus and RunKeeper seem to add some basic styling:
http://static.ak.fbcdn.net/rsrc.php/v1/yu/r/60YqMBkteVy.jpg
Short answer
No you can't.
Longer answer with more details
What you're looking for is called an Open Graph Action, it's not the usual Facebook status update. What you see in the screenshot linked by you, is an aggregation of all Open Graph Actions of a specific type.
You can not customize the layout of this aggregation. You can just select one of the 6 basic layouts and configure how the actions should be aggregated, sorted and/or filtered.
You can setup your own actions by going to the Facebook Developer Center, select one of your FB Apps, set a namespace in the basic settings (if not already done) and then got to "Open Graph". Once you've set up your own actions you can create your aggregations.
Here are a few links to get you started:
How-To: Defining an Aggregation
Open Graph Technical Guide
Open Graph Concepts
This is an awfully specific and awfully challenging issue. I know my chances of finding someone else with this problem are slim, but I have to try. I'm stumped.
I'm using Drupal 6, Ubercart, and the Option Images module.
I would like it to switch product images as different attributes are selected.
This works for certain images, but not for others. It seems to be tied to the attribute set, not anything about the image files--I've tried the same image on lots of attribute sets. I've also tried creating different attribute sets to see if I could figure out what aspect of the attributes is making option_images not work. No luck so far.
The Problem
For certain groups of attributes, option images will upload but they do not display on the product page.
Things I've Learned
Even for products that show broken option_images behavior, the images are uploaded. I see them in the database in the files table and on the filesystem.
There is an array on the product page I can see: '$node->option_images'. This array is populated for working product pages, and not populated for product pages that don't show option images.
When I turn on the database debugger, I can see that the database is queried (uc_option_image_load). On the broken pages though, it queries for images for the wrong product. (eg: it looks for sharp cheddar option images when it's on the swiss almond page) These products use different attribute sets.
Screenshots
I found it. The fact that it allows me to upload and preview option_images put me on the wrong path. It is actually a setting which enables and disables attributes for option images.
The setting is here: admin/store/settings/attributes
I think this is a usability bug, since letting me upload images for disabled attributes confused the heck out of me. But anyway. Solved.
Seriously questioning the Drupal way right about now.