tony
Week 44 25
2
Week 43 25
2
Week 42 25
2
Week 19 25
1
Week 41 24
2
Week 25 24
1
Week 20 24
2
Week 13 24
1
Week 11 24
1
Week 09 24
1
Week 08 24
1
Week 07 24
2
Week 06 24
1
Week 03 24
3
Week 02 24
4
Week 01 24
6
Week 52 23
8
Week 51 23
5
Week 50 23
7
Week 49 23
3
Week 48 23
4
Week 47 23
7
Week 46 23
9
Week 45 23
10
Week 44 23
7
Week 43 23
5
Week 42 23
7
Week 41 23
8
Week 40 23
10
Week 39 23
10
Week 38 23
22
Week 37 23
5
Week 36 23
1
Week 34 23
2
Week 32 23
1
Week 28 23
1
Week 25 23
1
Week 24 23
1
Week 21 23
2
Week 19 23
3
Week 18 23
7
Week 17 23
1
Week 16 23
2
Week 15 23
5
Week 14 23
5
Week 13 23
1
Week 12 23
7
Week 11 23
10
Week 10 23
2
Week 09 23
1
Week 08 23
3
Week 07 23
2
Week 05 23
1
Week 04 23
3
Week 03 23
1
Week 02 23
2
Week 01 23
9
Week 52 22
5
Week 51 22
3
Week 50 22
17
Week 49 22
3
All Posts Articles Meeting Notes
Tonic Labs
Week
42
Tonic Labs
Oct 14
Permalink Edit
Delete

  • Dec 14 Update

    • Morning Call

    • Start work on Framer site

Tonic Labs
Oct 13
Permalink Edit
Delete

  • Chat to Jen about using ContentEditable with PDF Templates and for loops

    • Problem: When exposing a liquid template in a contenteditable field, certain features of liquid templating break. The feature that's relevant currently, is the ability to use for loops, but there are other features that will break too.

    • Our potential options for this are:

    • 1. Build our own non-wysiwyg two-pane editor: This would consist of a code editor on the left, and a preview on the right. In this implementation, users would be able to use all liquid template features, like for loops, but they would need to edit the actual code - they would have no visual editor as they have now.

    • 2. Stick with contenteditable and write custom helpers on a case by case basis. This means that any time we want to use for loops in a pdf template, a developer would need to custom code something for that particular use case. This does preserve the visual editor but means non-technical users can't easily work with repeatable content.

    • 3. The Nuclear Option: Would be to find a solution that preserves both liquid templating and visual editing. There are wysiwyg editors out there, but the difficulty here is 1. Ensuring they support/preserve the structure of our current templates (many don't support tables/grids), and 2. Neatly integrating them with liquid features. The closest solution I've found for this is Dropkiq with Summernote (example here), but this is untested and unproven. For reference, even Shopify - who create Liquid and is built for non-technical people, doesn't expose a visual editor.

    • The big question: Should the visual edit feature of PDF templates be a core feature that should let Greenore staff have deep control over building and editing their templates, or is it a nice to have tool that will let them fix spelling mistakes, make minor changes to order and position. My sense is that it's the latter, and in that case I think we should stick with option 2 above, which is what I've asked Jen to do. @AJ if that's an incorrect assumption let us know and we can chat on the next call.

    • Research & Links

    • Customer.io in 2012 - Used whsihtml5 which is no longer maintained

    • Maglev - rails page builder

    • Dropkiq