How do we dissuade people from using the kit to make production sites?

[timpaul]

First of all - why is this A Bad Thing?

[joelanman]

Prototyping values these things:

• fast changes
• ease of use for non-developers

over these things:

• security
• maintainability
• performance
• accessibility

In general, production code values the second list over the first. Therefore there's a clear tension between prototype code and production code, as it's very hard (impossible?) to satisfy both.

[robinwhittleton]

While I wouldn’t recommend it, starting with a bare prototyping kit isn’t the worst way to start a production system. The trouble is that people will start with a tested prototype. There’s also the problem that it’s easy to draw an association between ‘looks like GOV.UK’ and ‘GOV.UK recommended way of starting a production system’.

[andymantell]

I'm working on exactly this right now... We have a prototype based on the toolkit and I've now been tasked with building a production ready version of it. So far my general experience has been a bit confused though as actually getting hold of the right css seems to be quite hard as it's spread across multiple repositories. There's some sass in govuk-elements-sass, some of it lives in govuk_frontend_toolkit and then there's some stuff in govuk_template_mustache. I feel like I've got myself into a bit of a mess so far, but I'm finding it hard to find the One True Definitive place where I can get all the styles.

Maybe I've missed something, I don't know. It just feels like there's stuff over those several repos that I need to collect together and I feel it could be a tad easier.

Note: This is not me moaning. Just wanted to convey my experience so far today.

[paulmsmith]

Still early days for me. Feel familiar with the prototyping kit (without actually using it on a project yet).

Can somebody kindly point me to what they consider a good example of a production site? and/or documents for the "recommended way of starting a production system" for gov.uk?

[jonhurrell]

I've put out toolkits in the past that weren't designed for production, but invariably end up in a production codebase. The lesson I've learnt is if you don't want people to use something, you have to provide an alternative/examples or communicate why something shouldn't be used for production. When I started, I asked multiple people a definition of production ready vs what's in the prototype and the answer still is unclear to me, all the repos I looked at are clear forks of the kit. I ended up building my own scaffold for Node/Express, with automated tasks (using gulp) pulling in the gov assets. However, I'm hitting the problems mention by @joelanman, due to differences between when the prototype was made and the current assets e.g.: form titles class removed, to use heading classes, however these have margin values that move the vertical rhythm out of sync. Am I to reset those with higher specificity rules, use my own rules, is the margin normalised now and the prototype needs to accept the increase in whitespace? Pragmatically I would have had nowhere near the time needed to rewrite everything, so am thankful the elements exist, but the tension is there.

[joelanman]

So there's a user need to know how to start a production codebase. And while we don't have that, the prototype kit is the closest thing, so that makes it likely to be used for something it's not intended for.

So one solution is to have clearer guidance and resources on making a production codebase.

[edwardhorsford]

The needs I've seen vocalised so far mostly revolve around production assets and templates - not necessarily an entire frontend.

[joelanman]

front-end production codebase?

[joelanman]

Just heard GOV.UK Pay frontend is based on the prototype kit :/

[paulmsmith]

Speaking just for myself as a new front-end developer to DWP (started less than three weeks ago). I think my need is just a set of basic principles for (and examples of) production sites/code.

As a former contractor, I'm used to arriving at a company and being told things like:

• We have a performance budget - Go read this URL or Familiarise yourself with these KPIs, etc.
• We follow BEM, ITCSS or 'Foo' CSS methodology.
• We run on a MEAN/LAMP stack and here is our skeleton/boilerplate/app/solution
• We use Backbone, React or 'Foo' Javascript Library.. we write functional, we do this, we never do that, etc, etc.

With that in mind, I suggest perhaps one of the reasons why the Prototyping Kit eventually rolls to production sites is that it has a boilerplate / scaffold feel to it. It comes with what seem to be production CSS partials, etc and depending on the environment could be seen as re-inventing the wheel or an extra step to port it from the kit to production.

Let's say myself as front-end developer, I work with all those required to build a service needed by DWP and we have used the prototyping kit and everybody is happy with it, it has passed assessments, testing, etc and is ready be put into production... What next? Is that what you're trying to say? There is no "one size fits all" solution and the kit shouldn't be treated as such?

Dare I suggest it could eventually become a kit that could produce production quality code? In a Rizzo Component API style? (See: Ian Feather's article & Ian's talk)? I'm talking purely for the front-end HTML/CSS/JS.

You might tell me "heck no" because you've discussed this until you all went blue in the face and decided against it for various valid reasons but I'm not sure they are clear to everybody that have used the kit.

Either way, I think it would be possible to utilise production CSS and assets in the prototyping kit, especially as that gives user testing sessions, a much closer experience of the proposed end-product.

It could become the single point of truth that some already seem to be considering it? Core assets and patterns that have been rigorously tested and proven, such as those listed in Elements could be configurable. Especially now that Nunjucks gives us macros combined with filters and call. We can define a standard component/pattern schema. For example:

Template calling macro

{{ 
  form.checkbox({
    id: 'terms-checkbox',
    api: {
      value: yes,
      label: "I agree",
      checked: true
    },
    metaData: {
      modifiers: ['inline'],
      classes: ['js-track-it','active']
    }    
  })
}}

Macro

{% macro checkbox(obj) %}
<label class="{{ 'form-checkbox' | componentClasses(obj.metaData) }}" {{ obj.id | attr("for") }}>
  <input type="checkbox" name="{{ obj.api.name | d(obj.id) }}" id="{{ obj.id }}"{{ obj.api.value | attr }}>
  {{ obj.api.label | d('Label text') }}
</label>
{% endmacro %}

HTML Output

<label class="form-checkbox form-checkbox-inline js-track-it active" for="terms-checkbox">
  <input type="checkbox" name="terms-checkbox" id="terms-checkbox" value="Yes">
  I agree
</label>

This would free users of the kit to only write actual HTML/CSS/JS for the bespoke aspects of their apps/sites. From there any useful patterns could be promoted to the kit should GDS or others feel they are worthy? I'm just spitballing here and If you made it this far, thanks. :)

[gemmaleigh]

@timpaul has this issue now been resolved? If so, could you please close this one.

There is a warning displayed the console, when developer tools are opened.

GOV.UK Prototype Kit - do not use for production

There is also a message displayed when the app is run

GOV.UK Prototype kit v3.0.0

NOTICE: the kit is for building prototypes, do not use it for production services.

Listening on port 3000   url: http://localhost:3000

[timpaul]

I think the immediate need has been met so I'm closing this issue. But I think there's another need along the lines of "I need to know that the thing I'm looking at is a prototype" - which is not met here.