by Erin RobotGrrl | Jan 3, 2020 | News, Progress Logs
Alright, so diving in to the tables again. It turns out the grid on twitter bootstrap runs on flexbox. Flexbox is just css, no javascript. So we can remove the other javascript stuff we included yesterday, which was probably causing the video playback on the front page to not work.
Figuring out flexbox was an interesting process. The first step was to try to see any examples. This page was good for that, but at the bottom it mentioned something about prefixing. Prefixing is essentially like some css snippets that make sure the proper ‘word’ is used depending on the browser. It looks like a cumbersome process – involving compiling css. Good for web developers to dive in to, but not so good if you’re trying to get stuff done.
Looking at this page, it seems most of the web browsers are okay to use css flexbox. Then came across this stellar example — flexplorer by Bennett Feely, and started to make sense of it. Using their css as a template, was finally able to get a flexbox css and divs to work out for the instruction rows. Some of the rabbit holes we got stuck in was about margins, and the flex-basis percentage and sizing.
Overall, with patience it started to work out. It’s always a nice thing to see something come together once you get a better understanding of the variables. Here’s the result, and it’s responsive too:
Alright, so what next? The initial problem is about editing and formatting a lot of steps for the instructions. What if the data could be saved as a json format, then have a python script to transfer it to whatever format after that? For example, it could be transformed into html after, or maybe it could be used for an app later, or something else. It will be a very convenient way to store the data, however we will have to make sure that any edits that happen on wordpress – we would be manually updating the json. Came up with a quick json breakdown of what this could be. Here is is visualised using this site.
It still doesn’t exactly solve the next issue at hand though, which is displaying a bunch of images in a way that will make it easy to see and edit for writing the descriptions. What if there could be a way to program a script to make a csv, and then import that to google sheets? Would it be able to display images? This was a simple test of the csv, it will need the part number in the future too.
Turns out, yes! It can display images loaded from elsewhere. This will be beneficial to organise the steps for the trio of kits that need the written descriptions done. In order to automate this, the next step will be to write a python script that gets the contents of a directory (of the photos), finds only the thumbnails, and then outputs the csv rows. From there, import into google sheets and then be able to write the descriptions. Export those as csv, and then with another python script, transport that to the json format, and then another python script to transport that to the html.
For the next kit log, we will be diving in to the python scripts to get the images into google sheets for writing the steps.
At some point the work done in google docs for the brain kit will need to be transferred to this format as well. It can be scriptable too, otherwise it’s a lot of manual work.
by Erin RobotGrrl | Jan 2, 2020 | News, Progress Logs
In the previous kit log we discovered that the current method of populating the instructions with content will be too time consuming and needs automation via a script. For this kit log, we did a comparison of various ways to display a table on our website (which runs wordpress). We also included google docs, which is what we were using for the drafts, as a benchmark.
Here are the qualities we were judging based on, and the weight:
Here was the result from various tests:
It is a tie between html tables and twitter bootstrap tables (aside: twitter bootstrap is a css web framework for any website to use as a style template to get started). The output responsiveness (ie, being able to “contract” to fit better on mobile screen sizes) of twitter bootstrap is better. But, it is less clear to edit because there are no borders around the cells in the wysiwyg editor. Whereas, this is the opposite for html tables. The tradeoff of a better output — which would likely be used more often than editing — is probably the better bet here. There will need to be some time spent for stylizing it, but this only has to be done once.
Leaning towards twitter bootstrap, but just noticing now that including some of its files has borked a few things. Like the video on the front page, and all the custom font styles and sizes. Maybe there is a way to include it without the default css. This will be something to look in to next kitlog before completely deciding on which one.
This is what all of the table tests looked like:
by Erin RobotGrrl | Jan 1, 2020 | News, Progress Logs
This kit log the instruction outline for the trio of kits was completed. The templates on google docs were created too. The super bright lights kit instructions ranges 16 steps, onto 10 pages. Operator interface kit ranges 31 steps onto 12 pages. Wheel / motor kit ranges 16 steps onto 7 pages.
When creating the templates from the outline into google docs, we were almost done then realised that we were listing out each step as a page, instead of vice versa. It didn’t take long to fix. There was enough time to start on the super bright lights kit instructions, by adding the images.
Adding an image takes quite a bit of manual input:
- select finder
- highlight image file
- drag onto google doc, enter
- back to finder, enter, copy file name
- back to google doc, in the right table cell, enter, paste file name
For the number of images we will be needing to add, it’s likely this is not going to be an approach that will be friendly on time. There could be ways of automating this – a simple python script could output the html for a table given the number range of images.
This would meen the first drafts would be on wordpress rather than google docs. It might make it more tricky for beta testers to directly add their feedback. Maybe if we included a numbering system for each step, then that would at least help for indexing the feedback to the steps? If we do skip the google docs then that meens we’re already formatting the content in its final medium, which might be beneficial to figure out.
The next step will be to set up some example formatting tests on the website, and see if html into the editor will turn into wysiwyg editor. The wysiwyg editor will be important in the future for editors to update it. In terms of making progress on the instruction written descriptions, it’s easier to do when looking at the images in sequence. This makes it better to understand if the order needs to be changed, or if something can be deleted. So getting this new step figured out will be first. The brain kit will be a good candidate to try this with since all the written descriptions are complete.
