Desirable Patternlab features

In GitLab by @tomdyson on Jan 9, 2018, 17:00

From Nick Lee's email:

Features in Patternlab

#6, Easy linking from patterns to other patterns (pattern lab uses {{ link.pattern-name }})
#91 Pattern status (In progress, In review, Signed off etc), see http://demo.patternlab.io/, patterns in the dropdown “Templates” and “Pages” have a coloured dot alongside to show the current state
Housing scss, json, js and twig/html templates in the same folder - allowing editors to quickly pull components from one project to another
#87 support for pattern variants – generate additional patterns with just a json file (in patternlab you can do "~pagename—modifier.json" and it’ll produce a page named modifier, based on the same template as pagename. http://patternlab.io/docs/pattern-pseudo-patterns.html)
Live page reload when assets change
Browser sync allowing editors to have tablet, phone and desktop browsers all controlled from the same device
#91 Ability to view html/css/js for each pattern within the pattern library
Search within pattern library for patterns (autocomplete - no need for a search results page)

Nice to have (not included in PL to my knowledge)

#93 Overview when viewing patterns showing which templates/pages they are used on (Clearleft’s PL seems to do this, see referenced by on the info tab here: https://patterns.boston.gov/components/detail/address.html)
#94 Something that Patternlab doesn’t have, is the option to easily showcase specific patterns on the pattern library homepage, would be great if we had this flexibility

In GitLab by @m1kola on Jan 9, 2018, 17:23

Easy linking from patterns to other patterns (pattern lab uses {{ link.pattern-name }})

We have a separate issue for this: #6

Housing scss, json, js and twig/html templates in the same folder - allowing editors to quickly pull components from one project to another

It's already possible. The pattern library doesn't have any front-end tools and it's something that must be implemented using a FE bundler (rollup/webpack/whatever). The bundler should collect css/js/images from pattern dirs and put result in a directory where Django can collect the resulting files.

Live page reload when assets change

Browser sync allowing editors to have tablet, phone and desktop browsers all controlled from the same device

I'm not sure, but it also seems like something that should be implemented using FE tools.

Ability to view html/css/js for each pattern within the pattern library

We can show html, not sure about css and js. Because scss for pattern can include another scss, for example. Is it really important? I think devs can always find related code in the repo. I don't think clients are interested in code.

In GitLab by @m1kola on Jan 9, 2018, 17:29

Good to have this list of desired features. Thanks Nick!

In GitLab by @chris-lawton on Aug 3, 2018, 16:54

After having spent some time using this on a client project, a couple of features i'd like to see are:

#98 Show the pattern name rather than the file path
#97 Perhaps just link straight to the pattern if there's only one, rather than having to click the category name and then the pattern
#96 List patterns in alphabetical order
Ability to search for a pattern
Improve mobile testing E.g. be able to access Mikalab from my phone and test on a real device (maybe a wider conversation)
#95 Ability to persist menu state

Just reading through the initial list above - we now have livereload via browsersync - i'm guessing we want this to be part of Mikalab out of the box rather than on a per-project basis?

In GitLab by @m1kola on Aug 3, 2018, 17:47

Chris, thanks for the feedback. All sounds good. The only one thing I would like to comment on is:

Just reading through the initial list above - we now have livereload via browsersync - i'm guessing we want this to be part of Mikalab out of the box rather than on a per-project basis?

I think, this should be a project thing. I don't want the pattern library to dictate projects which FE tools to use to build project. I want people to be able use it with webpack or rollup or with pure CSS and JS.

In GitLab by @nmorduch on Dec 4, 2018, 18:03

I also have some thoughts (many thoughts). Note that I love the pattern library very very much, and though I would love to change some of these things, having it at all is such an amazing improvement over not having it, and there are many things about it that I find very very clever and helpful.

A set of improvements related to pattern library chrome and browsersync

A few things that could be improved that could be solved together:

checking accessibility gives errors about the pattern library chrome as well as about the feature you're testing
the full-screen button is just an aesthetic change on the same page, so you lose the full-screen view when the page refreshes
i also like to switch between localhost:8000 (no reloading, doesn't rely on npm, good for keeping things open for reference without using all my computer's resources) and localhost:3000 (auto-reloading but breaks if npm isn't running things) and don't have an easy way to do this, especially because editing the url often doesn't work when browsersync is paying attention to your page

Some possible solutions to the above:

Have a page the just has links to all the rendered patterns, so that it can be used as an index. with links to:
- the pattern in the pattern library (in an iframe with all the chrome)
- the rendered pattern w/o browsersync
- the rendered pattern with browsersync
fix the things in the chrome that cause warnings about accessibility
have a button for turning the chrome on and off or switching between modes (think like the wagtail menu button you see when on a live page while logged in) and maybe remember whether the chrome is visible when switching between patterns

An established setup for situations where our pattern templates don't show everything

(edit @thibaudcolas: see #87)

overviews (e.g. here are all the types of buttons)
mockups (e.g. here is just a plain page with a functional modal, but it's not what you would use to include the modal)
what something looks like with every permutation of fake data

this could possibly be accomplished with some combination of:

a folder for overviews and mockups (or one for each)
a setup where you write in the yaml that there are multiple versions of the data, and then when viewing the pattern library you get an overview page or you get the pattern but with the option to select which data set you want. e.g.:

contexts:
  display: switcher
  - name: No introduction
    context:
      page:
        title: Page Title
  - name: Short intro
    context:
      page:
        title: Page Title
        introduction: Introduction to page
  - name: Long intro
    context:
      page:
        title: Page Title
        introduction: Lorem ipsum dolor sit amet, consectetur adipiscing elit. Quisque laoreet ante ac sapien eleifend tincidunt id ac diam.

contexts:
  display: overview
  - name: .button
    template: button.html
    context:
      label: Default button
  - name: .button--alt
    template: button.html
    context:
      label: Alt button
      classes: button--alt
  - name: .button--large
    template: button-large.html
    context:
      label: Large button

A few misc possible changes

#83 don't have the pattern library mandate a certain file structure (not actually sure whether this is currently the case)
#98 i agree about showing titles of patterns rather than file names, and not having so much digging through folders
make it more obvious how to hide the sidebar ~~make it possible to hide the sidebar~~ @chris-lawton points out that this can be done with the x in the upper left that i had never noticed
put the content above the iframe in the navbar so that it takes up less vertical space
#100 an option to show multiple screen sizes next to each other at the same time
#101 an option to define the breakpoints on a per-project basis (then they would match the names in the scss vairables)
#102 display the current iframe dimensions and allow manually changing them by dragging the corner or whatever
#10 is it possible to get templatetags to work in a less hacky way? i'm assuming that if yes it would be a whole lot of work and that's why it hasn't happened.

In an attempt to make the project’s backlog of enhancements easier to keep track of, I have created open issues for anything on this list, and will now close this. I imagine some of these features might make more sense to be built together, but tracking-wise it’s much easier if we can consider them in isolation.