dc2007git
commented
1 month ago [ discussion with @eatyourpeas ] we should try to make the Visit Form all on one page, without any scrolling (tabulation and pagination is fine)
To that end, we think using a tab system, where each tab is a care step. So every window is a different appointment or part of the appointment. For example, tab 1 would be the mandatory fields that should be filled out on EVERY visit, tab 2 could be those done at annual review, etc.
[discussion with @mbarton]
I have been working on Daisy and tailwind, and integrating those into the 'add new patient' form and also the 'patient visit' form in NDPA. I noticed that Daisy and tailwind both have their strengths, but there are also some considerations to be made about going forward with both.
First of all with the add new patient form. This is a much simpler form containing only text areas and drop-down boxes and a couple of buttons at the bottom of the form. Daisy provides text areas, drop-down boxes, and buttons, but one key thing that I noticed was that these styles that Daisy introduced were quickly over written by the styling of the RCPCH style guidelines. It is then worth noting that Daisy will be more useful to us when we are utilising its more complex component library such as sidebars, nav bars, accordions etc.
What is also important to consider is Daisy and Tailwind's interactions with Django. To create a Django form you must first have a model. Each field in the form should correspond to a field in the model, because you are trying to collect data and entries of that model, through which the form is the medium. When you are designing a form, you specify the type of input that will correspond to a particular field. For example, if I would like to choose a child's diagnosis of diabetes types, then I will set that field in the form equal to a 'drop down'. In HTML, this drop-down is equivalent to a select tag. When Django compiles the form, it essentially injects a pre-rendered HTML form into the webpage, meaning that we cannot apply styling in line in the HTML, and we must pass our styles directly to the Django form, specific to the field we wish to style. This means that our tailwind styles will not actually be present in the HTML form but in our python code for the form instead. This then removes the tidiness aspect of tailwind where we can have all of our styling done in line instead of what is having to happen, where we have styling in two different places.
One potential solution to this, which is what this pull request implements, is to deconstruct the pre-rendered HTML from Django reconstruct it for example as a select tag, and then pass in our styles in line. Alternatively styles can be passed directly to the form as described above, but because we are using a CDN any custom classes or Daisy components cannot be. If we were to utilise a tailwind build, however we believe that this problem would be alleviated and we could pass in custom classes directly to the Django form so option one is to pass styles into the Django form directly in the python code and not have to deconstruct anything (which looks tidier), and option two is to deconstruct the Django form in the HTML where we can then pass in our styles and custom styles (if we are using a CDN) in-line.
At the end of our discussion, we were leaning more towards keeping Daisy for the sole purpose that it's larger and more complex components will be much easier to implement and to reproduce if we were to design them from scratch ourselves.
Changes in PR